-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
base: trunk
Are you sure you want to change the base?
Conversation
.github/ISSUE_TEMPLATE/Epic.md
Outdated
<!-- | ||
An Epic should define a higher-level package of work or project iteration that, once finished, makes sense to merge in core. | ||
--> | ||
## Description ## |
There was a problem hiding this comment.
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.
.github/ISSUE_TEMPLATE/Epic.md
Outdated
## Description ## | ||
<!-- The what --> | ||
|
||
## Rationale ## |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
.github/ISSUE_TEMPLATE/Epic.md
Outdated
## Rationale ## | ||
<!-- The why --> | ||
|
||
## Stakeholders ## |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.)
.github/ISSUE_TEMPLATE/Epic.md
Outdated
## Stakeholders ## | ||
<!-- The who. This could include developers, designers, accessibility folks, testers, devrel, PMs... --> | ||
|
||
## Dependencies & Other Context ## |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)?
.github/ISSUE_TEMPLATE/Epic.md
Outdated
Link here any relevant Overview issues or posts that provide context | ||
--> | ||
|
||
## Acceptance Criteria & Required Scope ## |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
|
||
## Acceptance Criteria & Required Scope ## | ||
<!-- | ||
Please include here all the necessary bits and pieces to launch this package of work in a major WordPress release. |
There was a problem hiding this comment.
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.
.github/ISSUE_TEMPLATE/Epic.md
Outdated
- [ ] | ||
- [ ] | ||
|
||
## Nice-to-haves ## |
There was a problem hiding this comment.
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?
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. |
There was a problem hiding this 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 🙂
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 👍 |
Do we want to standardize the usage of Epic issues in WordPress 6.6 cycle? |
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
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"
I've updated the template to use "Iteration" instead of "Epic". Context in WP Slack.
I would say we want to leverage more iteration issues, but I'm having second thoughts about whether a template is needed 🤔 |
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 |
What?
Adds a new issue template for creating
Iteration
issues.Why?
When working with
Tracking
andOverview
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
Iteration.md
file in Preview mode.