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

Project Management: Add an Iteration GitHub issue template #56222

Open
wants to merge 3 commits into
base: trunk
Choose a base branch
from

Conversation

priethor
Copy link
Contributor

@priethor priethor commented Nov 16, 2023

What?

Adds a new issue template for creating Iteration issues.

Why?

When working with Tracking and Overview issues that span across multiple WordPress releases, we lack a way to track smaller but non-atomic pieces of work that represent project iterations and have clearly defined acceptance criteria to ship in a major WordPress release.

How?

By creating a GitHub issue template with different sections, including minimum requirements/acceptance criteria.

Testing Instructions

  • Check the Iteration.md file in Preview mode.
@priethor priethor added the [Type] Project Management Meta-issues related to project management of Gutenberg label Nov 16, 2023
@priethor priethor self-assigned this Nov 16, 2023
<!--
An Epic should define a higher-level package of work or project iteration that, once finished, makes sense to merge in core.
-->
## Description ##
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need a description heading, but rather a comment to indicate adding the description.

## Description ##
<!-- The what -->

## Rationale ##
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps "Why" is better label, removing the comment too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, I was on the fence of using the same format as the PR template (What, Why)

## Rationale ##
<!-- The why -->

## Stakeholders ##
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we have this? Will it be filled out?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure, probably not. On the one hand, it could sometimes be useful to list them, but on the other, most stakeholders are going to be recurring (design and a11y team, Matías, etc.)

## Stakeholders ##
<!-- The who. This could include developers, designers, accessibility folks, testers, devrel, PMs... -->

## Dependencies & Other Context ##
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe "Blockers", which are essentially the high priority items to do.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mmm... wouldn't that directly belong to the main category of tasks (MVP/required tasks)?

Link here any relevant Overview issues or posts that provide context
-->

## Acceptance Criteria & Required Scope ##
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd just make this "Tasks" perhaps. Reduces the complexity a bit, and makes it a bit easier to understand what you should add.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would be an easier way to say Acceptance criteria? Required tasks? What I want to emphasize is that any task listed in this section is absolutely necessary: if a single one is missing, the feature is not ready, whereas if all of them are finished, it means it's ready for inclusion in core.

.github/ISSUE_TEMPLATE/Epic.md Outdated Show resolved Hide resolved

## Acceptance Criteria & Required Scope ##
<!--
Please include here all the necessary bits and pieces to launch this package of work in a major WordPress release.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is necessary comment. Just another one kinda in the way when creating.

- [ ]
- [ ]

## Nice-to-haves ##
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need this section. Maybe "Follow-ups" to not loose the additional stuff not scoped originally?

@priethor
Copy link
Contributor Author

Thanks for the review, Rich! 🖤 For context, I updated and reduced the template from different Agile ones, but I agree there is still room to simplify it more and avoid friction.

Copy link
Contributor

@andrewserong andrewserong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be worth adding a Merged PRs heading, too? Not necessarily something that folks would always use, but I find it helpful having a Merged PRs section for some of my tracking issues so that already completed work can easily be found (it can help a bit for visibility when debugging recent changes related to a particular piece of work).

Feel free to skip that idea if it's not something generally applicable, though 🙂

@priethor
Copy link
Contributor Author

Would it be worth adding a Merged PRs heading

I'd rather have a separation between the musts and the follow-ups or nice-to-haves rather than by status, but I'm open to the idea!

@andrewserong
Copy link
Contributor

I'd rather have a separation between the musts and the follow-ups or nice-to-haves rather than by status, but I'm open to the idea!

Gotcha! The way this template is structured around MVP vs Follow-ups seems like the right focus to me 👍

@gziolo
Copy link
Member

gziolo commented Mar 8, 2024

Do we want to standardize the usage of Epic issues in WordPress 6.6 cycle?

Copy link

github-actions bot commented Mar 8, 2024

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: priethor <priethor@git.wordpress.org>
Co-authored-by: richtabor <richtabor@git.wordpress.org>
Co-authored-by: andrewserong <andrewserong@git.wordpress.org>
Co-authored-by: gziolo <gziolo@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Changes the wording "Epic" for "Iteration"
@priethor
Copy link
Contributor Author

priethor commented Mar 26, 2024

I've updated the template to use "Iteration" instead of "Epic". Context in WP Slack.

Do we want to standardize the usage of Epic issues in WordPress 6.6 cycle?

I would say we want to leverage more iteration issues, but I'm having second thoughts about whether a template is needed 🤔

@gziolo gziolo changed the title Project Management: Add a Epic GitHub issue template Mar 27, 2024
@gziolo
Copy link
Member

gziolo commented Mar 27, 2024

I updated the title and description of PR to reflect the latest direction. It would be useful to have a template but it might be more effective updating some existing issues to account for the case when someone mirrors prior art when opening a new Iteration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Project Management Meta-issues related to project management of Gutenberg
4 participants