Information about issue-priorities.md & new folder#7469
Conversation
mrjoro
left a comment
There was a problem hiding this comment.
Thanks for sending this out @adelinamart!
Contributing/Issue_Priorities.md
Outdated
| --> | ||
|
|
||
| ## AMP GitHub Issue Priorities | ||
| The AMP team is introducing the below priorities and guidelines to make it easier to order issues by the level of attention they need. |
There was a problem hiding this comment.
Since this documentation is intended for reference, I don't think it needs to refer to us "introducing" it or it being new. We can send a separate announcement via the various channels once this is merged in.
Contributing/Issue_Priorities.md
Outdated
| The AMP team is introducing the below priorities and guidelines to make it easier to order issues by the level of attention they need. | ||
| These new guidelines can give you also a good overview of when to expect updates or closure of issues. | ||
|
|
||
| In order to add a priority to your issues use our [list of GitHub labels](https://github.com/ampproject/amphtml/labels). |
There was a problem hiding this comment.
Are we expecting filers to set their own priority on issues? If so, we should set the expectation that they are hints, but that there is a process for adjusting the priorities. (We should also be very transparent for how those priorities are set.)
There was a problem hiding this comment.
Added a new sentence about this
Contributing/Issue_Priorities.md
Outdated
|
|
||
| Priority | What it means | Guidelines for Bugs | Guidelines for FRs | ||
| --------------------| ---------------------- | ---------------------------------| --------------------------------- | ||
| P0: Drop Everything | <ul><li>Outage</li><li>Critical production issue</li></ul> | <ul><li>Drop everything until this is fixed</li><li>Should be assigned and accepted within 24 hours of filing</li><li>Provide regular bug update on status and ETA of the fix, once every day after acceptance</li><li>Fixed in 7 days (next release or patch release, whichever is sooner)</li></ul> | <ul><li>A FR is almost never a P0</li></ul> |
There was a problem hiding this comment.
"almost never" in "A FR is almost never a P0" feels like it leaves some wiggle room that I don't think is there. I can't imagine a feature request that we'd tell people not to stop working on it until it was done, whereas a P0 may have that expectation.
There was a problem hiding this comment.
ok. Since didn't wanted to leave it blank added a new sentence
Contributing/Issue_Priorities.md
Outdated
| Priority | What it means | Guidelines for Bugs | Guidelines for FRs | ||
| --------------------| ---------------------- | ---------------------------------| --------------------------------- | ||
| P0: Drop Everything | <ul><li>Outage</li><li>Critical production issue</li></ul> | <ul><li>Drop everything until this is fixed</li><li>Should be assigned and accepted within 24 hours of filing</li><li>Provide regular bug update on status and ETA of the fix, once every day after acceptance</li><li>Fixed in 7 days (next release or patch release, whichever is sooner)</li></ul> | <ul><li>A FR is almost never a P0</li></ul> | ||
| P1: High Priority | <ul><li>Breakage of a critical feature or user journey</li><li>Highly significant feature</li></ul> | <ul><li>Should be assigned and accepted within 48 hours of filing</li><li>Should be updated by the team once every week after acceptance</li><li>Fixed within 30 days (next release) or updated with explanation and timeline</li></ul> | <ul><li>Implementation guidelines: 2 weeks</li><li>Feature requests are not P1, unless a situation develops where the lack of the feature is significant user problem</li></ul> |
There was a problem hiding this comment.
"Fixed within 30 days (next release)." Are we saying "fixed in the next release, which will always be within 30 days?" Or "fixed by the next release after 30 days."? If the former I'd rephrase this as "fixed in the next release (within 30 days)."
For the FR part, "unless a situation develops where the lack of the feature is a significant user problem" is too ambiguous. My sense is that it's quite common for someone filing a FR to feel like it's addressing a "significant user problem" so I think we need more stringent terminology here.
There was a problem hiding this comment.
ok. I added a general example, but I do want to leave room for some flexibility here on how to use this one (mainly at our end).
Contributing/Issue_Priorities.md
Outdated
| --------------------| ---------------------- | ---------------------------------| --------------------------------- | ||
| P0: Drop Everything | <ul><li>Outage</li><li>Critical production issue</li></ul> | <ul><li>Drop everything until this is fixed</li><li>Should be assigned and accepted within 24 hours of filing</li><li>Provide regular bug update on status and ETA of the fix, once every day after acceptance</li><li>Fixed in 7 days (next release or patch release, whichever is sooner)</li></ul> | <ul><li>A FR is almost never a P0</li></ul> | ||
| P1: High Priority | <ul><li>Breakage of a critical feature or user journey</li><li>Highly significant feature</li></ul> | <ul><li>Should be assigned and accepted within 48 hours of filing</li><li>Should be updated by the team once every week after acceptance</li><li>Fixed within 30 days (next release) or updated with explanation and timeline</li></ul> | <ul><li>Implementation guidelines: 2 weeks</li><li>Feature requests are not P1, unless a situation develops where the lack of the feature is significant user problem</li></ul> | ||
| P2: Soon | <ul><li>Breakage of a non-critical feature or user journey</li><li>Major usability problem (users frequently do the wrong thing)</li><li>Important feature</li></ul> | <ul><li>Best effort</li><li>Fixed in a quarter</li></ul> | <ul><li>Implementation guidelines: 1 Quarter</li><li>Generally higher priority feature requests</li><li>These are mostly features that have been specifically scheduled to meet OKRs</li</ul> |
There was a problem hiding this comment.
I don't think we refer to OKRs anywhere else in the open source project, so we should remove this.
There was a problem hiding this comment.
ok. replaced with roadmap since they know about that.
Contributing/Issue_Priorities.md
Outdated
| P0: Drop Everything | <ul><li>Outage</li><li>Critical production issue</li></ul> | <ul><li>Drop everything until this is fixed</li><li>Should be assigned and accepted within 24 hours of filing</li><li>Provide regular bug update on status and ETA of the fix, once every day after acceptance</li><li>Fixed in 7 days (next release or patch release, whichever is sooner)</li></ul> | <ul><li>A FR is almost never a P0</li></ul> | ||
| P1: High Priority | <ul><li>Breakage of a critical feature or user journey</li><li>Highly significant feature</li></ul> | <ul><li>Should be assigned and accepted within 48 hours of filing</li><li>Should be updated by the team once every week after acceptance</li><li>Fixed within 30 days (next release) or updated with explanation and timeline</li></ul> | <ul><li>Implementation guidelines: 2 weeks</li><li>Feature requests are not P1, unless a situation develops where the lack of the feature is significant user problem</li></ul> | ||
| P2: Soon | <ul><li>Breakage of a non-critical feature or user journey</li><li>Major usability problem (users frequently do the wrong thing)</li><li>Important feature</li></ul> | <ul><li>Best effort</li><li>Fixed in a quarter</li></ul> | <ul><li>Implementation guidelines: 1 Quarter</li><li>Generally higher priority feature requests</li><li>These are mostly features that have been specifically scheduled to meet OKRs</li</ul> | ||
| P3: When Possible | <ul><li>Minor usability problem (users are annoyed)</li><li>Polish</li><li>Minor features</li></ul> | <ul><li>Best effort</li></ul> | <ul><li>When possible</li></ul> |
There was a problem hiding this comment.
"Minor usability problem (users are annoyed)" might lead to some philosophical discussions ("is annoying users really a minor problem?") I'd just leave this as "Minor usability problem."
| @@ -0,0 +1,32 @@ | |||
| <!--- | |||
There was a problem hiding this comment.
Please lowercase the file names are replace _ with -
…sue-priorities.md
contributing/issue-priorities.md
Outdated
| ## AMP GitHub Issue Priorities | ||
| The AMP team is introducing the below priorities and guidelines to make it easier to order issues by the level of attention they need. | ||
| The AMP team is using the below priorities and guidelines to make it easier to order issues by the level of attention they need. | ||
| These new guidelines can give you also a good overview of when to expect updates or closure of issues. |
There was a problem hiding this comment.
"These guidelines" instead of "these new guidelines"
contributing/issue-priorities.md
Outdated
| These new guidelines can give you also a good overview of when to expect updates or closure of issues. | ||
|
|
||
| In order to add a priority to your issues use our [list of GitHub labels](https://github.com/ampproject/amphtml/labels). | ||
| In order to add a priority to your issues use one from the [list of GitHub labels](https://github.com/ampproject/amphtml/labels). Do expect the issue priority may change depending on the team's roadmap and backlog. |
There was a problem hiding this comment.
Do we want to make it completely optional for the filer to set a priority? In that case, I think we can phrase this as:
"If you would like to give a hint regarding the priority of the issue you can add the appropriate priority GitHub label. Note that the priority may be changed as the issue is triaged based on the project's roadmap and backlog."
contributing/issue-priorities.md
Outdated
| Priority | What it means | Guidelines for Bugs | Guidelines for FRs | ||
| --------------------| ---------------------- | ---------------------------------| --------------------------------- | ||
| P0: Drop Everything | <ul><li>Outage</li><li>Critical production issue</li></ul> | <ul><li>Drop everything until this is fixed</li><li>Should be assigned and accepted within 24 hours of filing</li><li>Provide regular bug update on status and ETA of the fix, once every day after acceptance</li><li>Fixed in 7 days (next release or patch release, whichever is sooner)</li></ul> | <ul><li>We do not use P0 for FRs</li></ul> | ||
| P1: High Priority | <ul><li>Breakage of a critical feature or user journey</li><li>Highly significant feature</li></ul> | <ul><li>Should be assigned and accepted within 48 hours of filing</li><li>Should be updated by the team once every week after acceptance</li><li>Fixed within 30 days or updated with explanation and timeline</li></ul> | <ul><li>Implementation guidelines: 2 weeks</li><li>Feature requests are not P1, unless a situation develops where the lack of the feature is significant user problem (eg. lack of the feature may block a significant number of AMP implementations)</li></ul> |
|
Done with all the changes. Thanks for the feedback. Let me know if someone can merge this. Thanks. |
I created a new file to add the issue priorities and guidelines.
I added a new folder for it so we can maybe move other files like contributing.md and developing.md under this one also.
@rudygalfi for feedback also