Confirmed users
1,085
edits
Accessibility/Meetings/2012-05-02: Difference between revisions
→Patch Review
DavidBolter (talk | contribs) No edit summary |
DavidBolter (talk | contribs) |
||
| Line 18: | Line 18: | ||
== Patch Review == | == Patch Review == | ||
We discussed how to speed up our review cycle: | We discussed how to speed up our review cycle: | ||
* New vs Existing. We observed that new feature work (for new users) can have a different standard of requirements than changes to existing code (with users). Specifically, in order to get features into the hands of users we need to land stuff that works and | * New vs Existing. We observed that new feature work (for new users) can have a different standard of requirements than changes to existing code (with users). Specifically, in order to get features into the hands of users we need to land stuff that works and is good and block only if necessary. '''So strive for an r+ if the patch is decent and doesn't break things, file follow ups, ask for QA, get back the follow ups later'''. With existing/legacy code our bar is higher and we can be meticulous as time permits. The goal of getting to the perfect patch is well intended and more practical here. | ||
* We noted that there are different rates of development for different teams or features and that this probably directly relates to the 'new vs existing' distinction. | * We noted that there are different rates of development for different teams or features and that this probably directly relates to the 'new vs existing' distinction. | ||
* Strive for a minimum of 24 hour turn around time on questions and answers in bugs. | * Strive for a minimum of 24 hour turn around time on questions and answers in bugs. | ||
* We noted that the bar for bug fixing might be quite different for different teams. | * We noted that the bar for bug fixing might be quite different for different teams. | ||