Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tools for grouping PRs by focuses #27448

Closed
2 of 4 tasks
oandregal opened this issue Dec 2, 2020 · 13 comments
Closed
2 of 4 tasks

Tools for grouping PRs by focuses #27448

oandregal opened this issue Dec 2, 2020 · 13 comments
Labels
[Package] Project management automation /packages/project-management-automation [Type] Enhancement A suggestion for improvement.

Comments

@oandregal
Copy link
Member

oandregal commented Dec 2, 2020

The tool that we use for Gutenberg releases comes with a changelog generator that pulls the title of the PRs bundled in the corresponding milestone and groups them together (see releases). Curating this changelog is now the more time-consuming part of the release process, so it'd be convenient to streamline.

Additionally, we now have a few sources for keeping up with all the work that is going on, see:

  • Weekly: core editor summaries (example)
  • Bi-weekly: release posts (example)
  • Monthy: what's next? (example)

and they don't always group the info in the same way. By grouping the info in all places into the same focuses we have for phase 2 and site editing milestones, there'll be more clarity around what's going on in each area.

Tasks

  • Create/Rename existing set of labels by focus. See phase 2 focuses, and site editing milestones.
  • Improve changelog generation #27744 Changelog generator: update how it groups the PRs.
  • Changelog generator: adding subgroups within each section (group PRs by focuses (FSE, global styles), block types, etc.
  • GitHub bot: suggest labels based on code + pings the PR author if it doesn't have one of the focuses labels.
@oandregal oandregal self-assigned this Dec 2, 2020
@oandregal oandregal added the [Package] Project management automation /packages/project-management-automation label Dec 2, 2020
@oandregal
Copy link
Member Author

oandregal commented Dec 2, 2020

Based on the phase 2 focuses and site editing milestones, this is the first draft I've come up with (will update as feedback comes):

Label/Focus What needs to be done
[Focus] Screen: Customizer Rename the existing Customization label (23 open). Remove Customizer (11 open) + tag the existing issues with the new label. Related: #13205
[Focus] Screen: Widgets Rename the existing [Feature] Widgets Screen (91 open). Related: #13204
[Focus] Screen: Navigation Rename the existing [Feature] Navigation Screen (40 open). There's also [Package] Edit Navigation (0 open) Related: #21340
[Focus] FSE: Block Navigation Rename [Block] Navigation (73 open tasks) Related: #13206 #18208 #20853 #21136 #20748 #20846 #21372
[Focus] FSE: Block Query Rename the existing [Block] Query (24 open). Related: #24762
[Focus] FSE: Theme Blocks Create the new label. Related: #22724
[Focus] FSE: Style System Rename the existing Global Styles (70 open). Related: #20331
[Focus] FSE: Infrastructure Rename the [Feature] Full Site Editing label (168 open) to the new name. Related: #20791 #24818
Tigtening up + New Features areas Any issue not categorized with some of the above label focuses will fall into this group.

cc @mtias @annezazu @youknowriad @draganescu @karmatosed @mapk what do you think of this? I'm mostly unsure about what to do with the [Focus] Screen: menu and [Focus] Navigation block.

@youknowriad
Copy link
Contributor

  • For me "customizer" and "widgets" go hand in hand. I'll defer to others but personally, I see these as the same focus.
  • should menu be "navigation screen" instead?
  • We should remove "patterns", it's not a focus anymore or at least not something worth having a dedicated focus.
  • Should we add FSE: something to all FSE related focuses to understand that these are part of the same global project?

Don't let my feedback block you, these things can evolve over time.

Also it would be good to have a way to tell the changelog script to mark some focuses as experimental and automatically put things there even if the "[type] experimental" label was not put on the PR.

@gziolo
Copy link
Member

gziolo commented Dec 3, 2020

Great idea, some comments regarding technical details for the transition:

Should we add FSE: something to all FSE related focuses to understand that these are part of the same global project?

There is [Feature] Full Site Editing that is applied to most of the existing issues related to FSE. It might need only renaming.

@annezazu
Copy link
Contributor

annezazu commented Dec 3, 2020

Thanks so much for doing this and getting this rolling!

I'm mostly unsure about what to do with the [Focus] Screen: menu and [Focus] Navigation block.

I'd recommend using [Focus] Screen: Navigation and [Focus] Navigation block. I think it's okay to keep navigation in both names as that's how we've been referring to them and there is inherent overlap in that work.

Should we add FSE: something to all FSE related focuses to understand that these are part of the same global project?

I agree with @youknowriad here as I think it would help a ton to have consistency in FSE related work as it's not always obvious at a glance if someone is new. This might also help drive home that FSE is actually a collection of work rather than "one project".

@mtias
Copy link
Member

mtias commented Dec 4, 2020

I'm not sure I understand how [Focus] should be used and what happens when it's no longer a focus but an established product area (like patterns).

@oandregal
Copy link
Member Author

OK, did a first-round and integrated your comments, this is the current proposal.

I'm not sure I understand how [Focus] should be used and what happens when it's no longer a focus but an established product area (like patterns).

@mtias I see them as short-lived, and they should be renamed back when they're no longer a focus. For example:

  • [Focus] FSE: Block Navigation => renamed to [Block] Navigation
  • [Focus] FSE: Block Query => renamed to [Block] Query
  • etc

Having a common prefix [Focus] intends to reinforce the messages in all channels (core-editor, release, monthly summary) and reduce the cognitive load when searching/tagging something. When someone ones to check a specific focus, they'll go to labels, search by "Focus", and the 5-10 labels we have at any point in time will show up there. It seems easier to do that than to remember (or learn) that it is [Block] for some focus, [Feature] for others, etc.

@gziolo I'm not opinionated about the specific names, but it's important to me that all of the labels have the same prefix, otherwise, we don't fix the discoverability issue. Happy to consider shorter prefixes than [Focus], but not sure which one?


Open the second round of feedback!

@gziolo
Copy link
Member

gziolo commented Dec 4, 2020

I was only concerned by 3 labels that have both feature and screen keywords. I don't think that it's a focus really, it's just a way to provide more context or grouping for issues.

@youknowriad
Copy link
Contributor

Yes, the main thing for me here is that I hope we can get back one hour or so from the time we spend preparing the changelogs. Doesn't solve everything but might help put things in the right place and the right section.

@draganescu
Copy link
Contributor

@youknowriad @nosolosw the customizer focus should be separate from the screens as the core of the matter there is totally different. For the screens the focus is to improve the experience those screens offer for their function and to add block management support. For the customizer the focus is to allow the customizer to "talk" to the block editor so that we can get a live preview of block edits and also to create a good experience of block editing with live preview.

Therefore:

  • it's ok to have three labels
  • @nosolosw the "Customization" label has nothing to do with the customizer, we should leave it as it refers to customisation of the block editor.

@oandregal
Copy link
Member Author

Thanks for the feedback, folks! While I like the clarity this kind of "grouping" could bring, it also comes with some downsides (some management when the focuses change, people involved in the issues/PRs still want the existing labels and know what they should use, etc). So, it doesn't sound like creating this new set of labels is something people would find valuable at the moment. This is what I'd like to do as the next steps:

  • Keep existing labels as they are ― no "focus" labels are created.
  • Use the existing labels to reduce the amount of time we invest in generating the changelog.

@oandregal
Copy link
Member Author

ok, got #27744 ready ― it improves a bit the changelog organization.

@oandregal
Copy link
Member Author

#27744 has landed. Updated the tasks in the issue description.

@oandregal oandregal removed their assignment Apr 22, 2022
@jordesign jordesign added the [Type] Enhancement A suggestion for improvement. label Sep 4, 2023
@oandregal
Copy link
Member Author

There hasn't been activity on this for years now, so I'm closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Package] Project management automation /packages/project-management-automation [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

7 participants