The original intent of the "J3/4 Issue" that I created was to identify issues only - PR already had the branch so didnt need anything but issues needed something. The word "issue" was used deliberately as it was not for pull requests and just for issues

As for adding it to the pr title - its a nice to have but I wouldnt bother adding it if it hasnt been done

Adding versions to titles only benefits those who are following by email primarily and want to set up notifications for specific things instead of using GitHub. Otherwise, a large bulk of this activity (especially en masse activity like what has been happening over the last few days) is largely doing nothing but burning through already limited API resources (even with a network of bot accounts that probably runs afoul of GitHub's ToS).

triage is hard

Version in title. Is really useful for email notifications. But wasn't you who suggested to remove categories in the tracker and replace it with labels?

Using labels could help classifying for people interested only in one kind of issue, I simply ignore them most of the time.

i was trying to get some stats from github and can confirm it's quite an hard task ?
so any proposal to better "filter" data is warmly welcomed from my perspective

Yes, I want to see tracker categories dropped and just use labels for that, it's the same capability implemented in two systems and only visible in one. But, last I checked the categories break things down into components (literally, every core component is represented there) or other sections and focuses of the application (Cache, SQL engines, things like "Feature Request" or "Accessibility", etc.), not "J4 Issue" and "J4 Backend Template" (which reads like a memorandum from the department of redundancy department).

Version in title. Is really useful for email notifications.

That to me is borderline misusing GitHub so you can more conveniently filter your emails. Every title change breaks Gmail's threading system because it changes the subject as an example. And what happens when people start submitting issues with titles like "[3.9.2] Foo", does someone go through and change the titles to "[3.9.3] Foo" if the issue isn't fixed before that release, or a more generic "[3.9] Foo" (which has the same problem if not fixed before next minor ships)?

It's not hard to subscribe or unsubscribe from issues if you are (or are not) interested. But using email as your primary interface to GitHub is probably a bad idea.

i was trying to get some stats from github and can confirm it's quite an hard task ?

GitHub issues have always been a glorified TODO list, that hasn't changed much since 2011. You're not going to extract too much useful data out of GitHub about anything without a lot of custom workflow logic. Unfortunately, it seems creating a proper issue tracking solution with basic features baked right in (akin to Trac or GForge or a custom solution like what Drupal uses) doesn't seem to be a roadmap item for them.

But using email as your primary interface to GitHub is probably a bad idea.

yes probably it is, but it is quite an easy and fast one way ... for lazy people.... like me ?

btw, from my experience is not matter of a tool.... that allows or not some features...as you already said
... there is a need of a lot of

custom workflow logic

when system's are quite complex ....

Well, unfortunately everyone kept coming up with reasons why every commercial issue tracking solution on the market in 2012 was a no-go for Joomla and I was young and naive enough to put my foot in my mouth and start up the issue tracker repo. If I ever perfect the art of time travel, remind me to head back to that summer day and slap myself silly ?

don't get me wrong ....i have a good perception on how it is hard to meter things,
plus add the context of a community driven project... complexity quickly became O(N^N) ?

Please don't forget that only a few contributers are allowed to set labels (or am I wrong?). You always need someone that is doing that job without too much delay. If the labels are always set in issues then that's perfect for filtering and I don't need more but if not I prefer the [4.x], [3.x], [whatever] markers for fast scrolling through the newest/recently updated issues on GitHub.

That to me is borderline misusing GitHub so you can more conveniently filter your emails. Every title change breaks Gmail's threading system because it changes the subject as an example.

You say I'm holding it wrong because your email client is broken? A working email client uses the reference header to display threads. But ok if the title is a problem for you, you maybe can explain me how to differ between J3 und J4 issues / PRs, because github doesn't include tags. Not in the header and not in the body.

I'm only talking about my own workflow and use what was already here. I'm using zero inbox and get all github mails into my inbox as every other mail. Based on the time I have I check the mails I'm mentioned (they get flagged by my server) then [3.9] mails (because they are more important for me as RL). Then I check [4.0] and unversioned Issues. [4.0] mails I may only read the subject and delete it but I don't want to unsubscribe because maybe later it gets more important for me.
The github interface is much slower then my native mail client.

Also I'm not sure what's your suggestion is. Based on your initial comment you want that all metadata is removed?

Maybe the overhead for "J4" in backend template true, I'm also not sure why "No Code Attached Yet" is added, because a issue can't have code attached and PR's always has code or i'm wrong? If you don't like it we can remove the "j4 issue" tag.

I'm also not sure why "No Code Attached Yet" is added, because a issue can't have code attached and PR's always has code or i'm wrong?

The issue tracker doesn't show issues and pull requests as a separate entity the same way GitHub does, that label was used as a way to distinguish the two. There are probably better ways to deal with it but that was one of the first ideas that came up and it just stuck.

And I don't mean to imply anyone's workflow is necessarily wrong, but I do think relying on email to do GitHub stuff more than just using GitHub isn't the best of ideas (it should be a supplement, not the primary). Before just turning it all off, I just always let all notifications go into a folder and then I filter things out on the issue's title or repo (since there are some repos where I get all notifications and a bulk of them just don't apply to me), I never particularly cared about the version being in the title because if the issue title and body are interesting enough to get my attention I can read a little more to find a version identifier.

I would be glad to change Stuff at Issue Tracker and Github that fits Developers and Users coming usually here to report an Issue.

Regarding using Labels at Github instead Categories at Issue Tracker: I would create all used Categories as Label in GH and assign them there and remove them from the Issues/PR at Tracker.

Please advice if existing Categorie or Label isn't needed in Future.

@brianteeman @mbabker @HLeithner @alikon @ReLater - which Categories should no be created as Labels? Of course everyone please comment :-)

I can't help too much here.

I visit GitHub 2, 3 times a day. First I look at the first open and closed entries under "Issue" and "PR".
Then I order both areas by "recently updated".

From my point of view labels PR-* only for PRs and labels JX Issue only for issues are sufficient to filter.

And descriptive titles and descriptions to use the search bar. But there I don't need additional version hints if the labels are set.

As long as these criterias are given I also can live with other additional labels.

I removed "J4 Issues" from Pull Requests as they got "PR-4.0-dev" automated by Bot. Haven't notices that before.

Moving from Issue Tracker-Categories to Github-Labels don't work in this Way. People of course use as always Categories, which are applied automated as Label. So it needs a Decision how to migrate. I suggest to discuss at Glip: cms-maintainers. If there is no interest its fine and all will be as now :-)

Looks like Discussion has ended. If its true, Issue will be closed.