Pods: GitHub Labels

~"Needs Changelog" as a label might be able to go. I've been making changelog updates part of the merge process and haven't been using that short-lived label.~
Done

I haven't had time to go through with a fine-toothed comb, but I'm not seeing anything immediately glaring in a first skim. I may find a few tweaks, omissions, deletions on a solid pass but my instincts are this would be a huge improvement over the current label system as proposed.

"Patch" is one I've never used in my workflow, as it seems redundant to me. If it's a PR, then it's a patch. But @sc0ttkclark has traditionally used that label, so it may have some workflow value for him.

~Component: Multi-site would be a good addition, that's another area like REST API, and Templates that would be helpful to start tagging for filtering purposes.~

Done

Focus: Backward Compatibility
Focus: Compatibility/Deprecation
Focus: Compatibility

For these three, perhaps refined:

Focus: Backward Compatibility
Focus: Deprecation
Focus: Third Party Compatibility

Edit: This is done

Besides that little stuff so far, I'm all GO on this. The classification is much better and I'd like to be using it though 2.7.7.

I do want to get an explicit thumbs up from @jimtrue and @sc0ttkclark as well, first.

What's the difference between Discussion and Team Discussion? Could they be replaced with Needs: Developer Feedback?

What is Integration?

Here's my second pass. A few new additions/changes. Those with leading question marks could be dropped if not being used:

Closed: Could not reproduce
Closed: Duplicate
Closed: Invalid
Closed: Out of scope
Closed: Won't Fix

Component: CSS
Component: docs.pods.io
Component: DFV
Component: Front-end Forms
Component: Multisite
Component: Pods Templates/Magic Tags
Component: REST API
Component: support.pods.io
Component: UI
Component: Unit Testing
Component: WP Admin

Focus: Accessibility
Focus: Backward Compatibility
Focus: Deprecation
Focus: Third-Party Compatibility
Focus: I18n
? Focus: Integration
Focus: Performance

? Keyword: Discussion
Keyword: Focus
Keyword: Forums
Keyword: Friends of Pods Priority
Keyword: Good First Issue
Keyword: Has Bounty
? Keyword: Patch: Manually Merged
? Keyword: Patch
Keyword: Plugin Material
Keyword: Puntable
Keyword: Release
Keyword: Support
? Keyword: Team Discussion
Keyword: Tools
Keyword: VIP

Needs: Developer Feedback
Needs: Research
Needs: Tasklist
Needs: Test(s)
Needs: User Feedback
Needs: Verification/Reproduction
Needs: Votes

Priority: Blocker

Type: Bug
Type: Code Standards
Type: Inline Documentation
Type: Enhancement
Type: Feature
Type: Refactor
? Type: Regression

Status: Fixed / Needs Testing
Status: Help Wanted
Status: Hold
Status: In progress
Status: Pulled for Review
Status: Ready for merge
Status: Ready for review
Status: Researched
Status: Unit Tested
Status: Verified/Reproduced

What's the difference between Discussion and Team Discussion? Could they be replaced with Needs: Developer Feedback?

Not much, Discussion would be open to the world and Team Discussion would be internal. I don't think we need that so fine-grained and a single generic discussion label is fine (the duplication was probably unintentional). Dev Feedback is generally used as a status, usually a ticket that was holding for user feedback and got said feedback.

What is Integration?

Primarily feature requests involving integration with other plugins, libraries, themes, etc. I suppose bugs on existing integration might fall under this umbrella but often those are more appropriate as "compatibility" once we have integration. (so Integration possibly a Type though maybe it makes more sense in Focus as you've done)

I'm not sure the 'Needs:" section is better... I liked the idea of those as part of "Status:" as I think that's often how they're used.

Edit: this has all been addressed

~I'm thinking the following Keywords might actually be Type: Release, Support, and Tools.~

~Those seem like types of tickets that aren't well described by any of the others.~

Done

Also, for the sake of scrolling I wonder if we should just keep the list in the initial message up to date rather than posting new versions as we go?

Done.

I do like the idea of this:

Needs: Developer Feedback
Needs: Research
Needs: Tasklist
Needs: Test(s)
Needs: User Feedback
Needs: Verification/Reproduction
Needs: Votes

But the 'User Feedback' and 'Verification/Reproduction' are really 'status/workflow' as @pglewis noted above or we could put those as Status: Blocker with the Needs being the 'reason' for the Blocker.

The status Workflow should ideally thin down to the swimlanes in the project. Looking at this list of labels, I had NO idea we had so many, but i'm guessing you guys created a handful more.

support.pods.io and docs.pods.io shouldn't be in here at all (we have repos for those two websites), unless we're planning on using GitHub for Support and Documentation updates. If we're going to do that (which I am ALL for) then we add a prefix for Docs: and Support: and create two projects in GitHub in this repository for Support and Documentation. Since occasionally a support problem might turn into an actual code enhancement/feature or bugfix, it does make sense for us to use the same interface. Sure we'll have more, but we'll also make sure we get exactly what we need for support problems and documentation updates.

I looked this over, and I'd like to see the following changes:

• Type: Add Support & Docs Update (removing Support from Keyword)
• Component: we don't need support.pods.io ordoc.pods.io in Component. Those two repo's have their own projects. Component should be entirely for the Pods Core area of focus.
• Priority: Move Focus from Keyword to Priority. Blocker is fine as long as we know the reason, which should be coming from Needs.

So if I follow this correctly, everything should have a:
Type: Defines what type of ticket it is.
Status: Defines where it is in the Workflow. Little discussion on what the Status should be 'Blocked' or 'ToDo' or 'Hold' if we Needs User Feedback or Verification/Reproduction. Not sure what the Status would be for Feature/Enhancement Request where the Needs is Votes. Maybe those follow the same format for a typical Kanban board and their status is BackLog until it's actively being worked. Blocker indicates it Can't be worked until the Needs is handled.
Component: Determines the area of Pods Core for Feature/Enhance/Bug
Keyword and Focus are just for additional clarification?

I removed WaffleBot so those statuses should no longer be automatically added.

Blocker indicates it Can't be worked until the Needs is handled.

Here's a case where we're not using a label with the same intentions. I've always used Blocker (and I think Scott as well) for issues that block a release (or maybe another ticket) and must be done; cannot be punted.

There is no reason in my workflow for me to mark something as holding on something via 'Blocker'... the current status labels should imply that. I don't need "Need User Feedback" plus "Blocker" as the first one already tells me it's blocking and why.

My vote is we use it that way and keep it under "Priority: *" as that's a perfect description to me.

~I think "Focus" should also move from Keywords to Priority.~ Leaving in keywords

I do like the idea of this:

Needs: Developer Feedback
Needs: Research
Needs: Tasklist
Needs: Test(s)
Needs: User Feedback
Needs: Verification/Reproduction
Needs: Votes

These are primarily ticket statuses to me so I'd propose keeping them there for now. If length is the concern we might abbreviate some ("Status: Need Dev FB", "Status: Need Verification/Repro").

I think "Needs Tasklist" can go. I don't think it happens enough to warrant a label. I'm not sure I've ever used it, rarely if so. Probably ditto for "Needs Tests". The remaining ones all fit perfectly for me under "Status: *".

Also, the list is shaping up nicely to me, we should probably discuss color scheme.

A couple more that can probably be trimmed from Statuses along with "Needs Tasklist":

• ~"Pulled for Review" is probably just unintended duplication of "Ready for Review"~ Leaving it
• "Unit Tested" isn't a status (not yet at least), more miscellaneous... so probably moved to Keywords?

That leaves the status list looking good to me.

"Pulled for Review" is probably just unintended duplication of "Ready for Review"

Disagree. If I create a PR, then when it's ready, I'd add Ready for Review. But you may not have time to do that review until later - but by then, Scott isn't sure if you've started the review or not. In short, it's two different groups of people adding Ready for Review and Pulled for Review.

Probably ditto for "Needs Tests".

For the sake of wanting more code coverage (though I've yet to personally look into this area much), this label could be for saying that "the fix is good, but we'd like to see unit tests cover the edges / verify the specific bug fix so no regressions are introduced".

I think "Focus" should also move from Keywords to Priority.

Priorities would generally be - low, medium, high, critical, blocker - they have different semantics (in my mind at least) to Focus. A Keyword: Focus label has no relevance on it's own unless there's a Milestone to say which release the issue is a focus _for_. Whereas a priority is contextless, in so much as it applies to the project as a whole. I don't necessarily think adding the other priorities is a good idea, but equally, don't think Focus is a priority. Maybe what we're trying to say is that "this ticket is a Milestone Highlight - a big goodie to shout about at the next release", and if so, a different word to Focus may be better to signal intent.

Blocker indicates it Can't be worked until the Needs is handled.

I'd agree with Phil here - I understood it to mean that the Issue that has this label is a blocker to a _release_. Maybe Jim's explanation would be better suited to a Status: Is Blocked label or similar, though a Needs: * would indicate the same.

BTW, is it okay to delete the interim list here: #5016 (comment) ?

@pglewis Go ahead and remove (or hide in <details>...</details> for historical reference) whatever you want.

support.pods.io and docs.pods.io shouldn't be in here at all

That was me adding them in due to uncertainty about the existing "Docs Improve" tag (vs Docs: inline) - they can be removed if they are handled elsewhere.

Docs Improvement might be better written as 'Docs: Inline' 'Docs: Examples' 'Docs: Tooltips' and that sort of thing. Unless we're handling Documentation (ie written documentation in the docs.pods.io website) workflow in GitHub, there's no reason for it in here. Any docs improvements inside our code means docs _in_ our code or managed within our code or like the readme that gets parsed and pushed up to the WordPress.org plugin repo.

I like the Status: Is Blocked as that's very informative, but if you do something of that nature, it does require a Needs:* as well

Like I said, everything gets a Type and a Status. Until we're doing full Agile Project Management with GitHub, the priorities don't need to be defined there and are actually better represented by the units of work required to get the 'story' done. We've always used Focus to differentiate items in the 100's of issues that need to be focused in the next maintenance release.

My only thoughts are with regards to UI/CSS labels, as those are the ones I deal with the most... it seems like maybe just removing CSS as a component and only relying on UI makes makes the most sense to me. Not sure if you guys have any thoughts there, but CSS is the result, not the tangible thing that needs to be fixed... if that makes sense. UI would be the tangible thing to be worked on or improved, css would be the result or how its fixed. Otherwise I like it 👍

My only thoughts are with regards to UI/CSS labels, as those are the ones I deal with the most... it seems like maybe just removing CSS as a component and only relying on UI makes makes the most sense to me. Not sure if you guys have any thoughts there, but CSS is the result, not the tangible thing that needs to be fixed... if that makes sense. UI would be the tangible thing to be worked on or improved, css would be the result or how its fixed.

Yeah, there is refinement to be done there. I've mostly used the CSS label as the Bat-signal for you and/or Jory to filter on since you've been the go-to guys in that direction.

I'd vote to leave CSS and UI as proposed for now but we can certainly continue to refine it after Phase I.

RE: Needs Tests

For the sake of wanting more code coverage (though I've yet to personally look into this area much), this label could be for saying that "the fix is good, but we'd like to see unit tests cover the edges / verify the specific bug fix so no regressions are introduced".

The reality is we need to keep up on maintenance fixes, work on a release branch, and the barrier to writing new tests is rather high even for simple things. We can leave the label there but it is not likely to be used very much until a lot more refactoring has been done, we introduce actual unit tests, and/or have more resources to devote to it.

A "Type: Tests" would be a good addition though because right now added tests are probably best as their own issue/PR pairs.

I like the Status: Is Blocked as that's very informative, but if you do something of that nature, it does require a Needs:* as well

I'm fine leaving it, but I'm primarily the one tracking statuses and I've never had a need for marking anything "is blocked" as a status. Anything that's vaguely that direction that I come across is better covered by "Holding".

And in case it helps clarify anything, this is the typical workflow I use on an average bug:

• Triage: filter out invalid, support, feature/enhancement; set type to bug
• Normally status immediately goes to "needs verify/repro"
• May go back and forth between "needs user feedback" and "needs dev feedback" through the lifespan
• Verified/Reproduced
• Needs Research: now that we know how to make it happen find out and understand why
• Researched: I'm probably the only one that uses this. Signals a deep dive has been done at some point and I probably have internal details stored in my head
• Fixed / Needs Testing

Disagree. If I create a PR, then when it's ready, I'd add Ready for Review. But you may not have time to do that review until later - but by then, Scott isn't sure if you've started the review or not. In short, it's two different groups of people adding Ready for Review and Pulled for Review.

I think a the Hold label has historically been better than Pulled for Review in those cases.

FYI, in the past, I have used Blocker to indicate an issue that blocks a release.

We can remove 'Patch', I started using that when GitHub had more confusing UX between PRs and Issues, it was easier to see the 'Release' view with Patches mainly for going back over things for changelog stuff. We don't need it.

Is the list in the original issue description up-to-date with the changes we've all discussed?

Is the list in the original issue description up-to-date with the changes we've all discussed?

Probably not completely, feel free to refine some if you want. I'll go through once we have full thumbs-up and comb for anything we've decided that hasn't been updated.

Whatever we decide here, we need to apply to all of our other Pods repos using a tool like https://github.com/dwyl/labels to sync them.

Moving "Regression" from Type to Keywords. Bug is still the type for regression issues.

This is pretty much implemented now. A few misc things I just stuck under "Keywords" for now.

Colors are the main thing to work out at this point.

?Closed: Invalid

I'd suggest keeping at least this one, possibly the Won't Fix as well. They are fairly standard resolutions on other bug trackers.

Colors are the main thing to work out at this point.

Colours are secondary at this point - get the labels implemented, and decide on a colour scheme later on.

I'd suggest keeping at least this one [Invalid], possibly the Won't Fix as well. They are fairly standard resolutions on other bug trackers.

I'll add Invalid, I just marked it as a reminder because we didn't have it already.

"Won't Fix" is one of those that I just hate the tone of. Plus my attitude is we should have a label with a better specific reason for not fixing something than "Won't Fix".

Colours are secondary at this point - get the labels implemented, and decide on a colour scheme later on.

Labels are pretty much implemented.

Do we need a "Type: GitHub" or something similar? This issue has no type.

Type: Project?

What if instead of "Won't Fix" we used "Leave as is" or something like that?

What if instead of "Won't Fix" we used "Leave as is" or something like that?

It's an uncommon situation thus we've made it this long without needing something like that. I vote to wait on adding anything there until a specific example turns up.

Also, I've made some arbitrary color decisions for some of the groups. Nothing is set in stone there.

I think we can probably close this issue at this point and discuss any further refinements via Slack.

What if instead of "Won't Fix" we used "Leave as is" or something like that?

It's an uncommon situation thus we've made it this long without needing something like that. I vote to wait on adding anything there until a specific example turns up.

I agree. Not everything that WordPress core does needs to be duplicated

I agree. Not everything that WordPress core does needs to be duplicated

It is also one of the default labels when setting up a new repo on GH - see https://github.com/GaryJones/daterange/labels which has the default labels.

I agree. Not everything that WordPress core does needs to be duplicated

It is also one of the default labels when setting up a new repo on GH - see https://github.com/GaryJones/daterange/labels which has the default labels.

I don't recall when it became a default for GitHub, but it's always been a terrible tag to attach to a ticket from a volunteer contributor. I've seen very few issues on GitHub with that tag but in the WordPress world most of the wont-fix tickets are covered by another issue, needs more information to justify a fix, or just hoping nobody comes back complaining (often the case).

I'll stick by my dislike. My immediate question on "Won't Fix" is "Why would we refuse to fix something?" And if someone gives me a good concise answer to that on a ticket I'd say _that_ is what the label should read rather than 'Won't Fix".

I think Out of Scope is a better answer there anyway. Won't Fix just implies and provides 'nothing' to the person opening the issue.

maybe it could go in the direction - feel free to submit a "solution" but the team doesn't have enough resources to do it :D maybe someone has an idea for a short abbreviation for it ^^

A use case might be a bug or CS violation in some feature, that is wholesale being rewritten and released in the next version anyway.

Feel free to leave it out though.