Hi folks,
In the ArchCom meeting earlier today, Daniel, Timo, Tim and I discussed the way we handle RFC assignments in Phabricator. Previously, the RFC would frequently be assigned to person writing the RFC. As we try out the Rust model (per T123606 https://phabricator.wikimedia.org/T123606), and as we try to increase the speed by which RFCs move though the process, we thought it would make sense to also assign RFCs to shepherds on the ArchCom.
We didn't discuss all of the implications of this in the meeting today, but we think this might help us scale our RFC triage process. What do you all think?
Rob
Sounds good, Rob, and All,
Thanks for all of your good work on this!
Scott
On Wed, Feb 3, 2016 at 8:28 PM, Rob Lanphier robla@wikimedia.org wrote:
Hi folks,
In the ArchCom meeting earlier today, Daniel, Timo, Tim and I discussed the way we handle RFC assignments in Phabricator. Previously, the RFC would frequently be assigned to person writing the RFC. As we try out the Rust model (per T123606 https://phabricator.wikimedia.org/T123606), and as we try to increase the speed by which RFCs move though the process, we thought it would make sense to also assign RFCs to shepherds on the ArchCom.
We didn't discuss all of the implications of this in the meeting today, but we think this might help us scale our RFC triage process. What do you all think?
Rob _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Rob Lanphier wrote:
In the ArchCom meeting earlier today, Daniel, Timo, Tim and I discussed the way we handle RFC assignments in Phabricator. Previously, the RFC would frequently be assigned to person writing the RFC. As we try out the Rust model (per T123606 https://phabricator.wikimedia.org/T123606), and as we try to increase the speed by which RFCs move though the process, we thought it would make sense to also assign RFCs to shepherds on the ArchCom.
We didn't discuss all of the implications of this in the meeting today, but we think this might help us scale our RFC triage process. What do you all think?
I guess https://www.mediawiki.org/wiki/Requests_for_comment/Governance tries to answer the question "what's a shepherd?"
--- * Nominate a shepherd from a (sub)team to guide an RFC through the process. ** Makes sure that stakeholders are informed. ** Guides the discussion. ** Once the discussion plateaus or stalls & in coordination with the RFC author(s), announces and widely publicizes a "Final Comment Period", which is one week. ---
I'm still not really sure what any of this means. The biggest focus seems to be on speed and throughput for the RFC process itself, when the focus should actually be code quality, sustainability, and overall architecture.
I found the recent RFC discussion about adding an expiration field to the watchlist table to be very disappointing. My impression was that people were more concerned with quickly pushing through a new feature (with unknown user interface implications) than with solving the deeper underlying problems we have with page lists.
MZMcBride
Rob, MZMcBride and All,
And what's a shepherd in relation to the facilitator of any specific committee (if this is relevant)?
Can someone please circulate a summary of RUST decision-making again? (Is this relevant - https://oqi.wisc.edu/resourcelibrary/uploads/resources/Project_Prioritizatio... ?)
Thank you, Scott
On Thu, Feb 4, 2016 at 7:08 AM, MZMcBride z@mzmcbride.com wrote:
Rob Lanphier wrote:
In the ArchCom meeting earlier today, Daniel, Timo, Tim and I discussed the way we handle RFC assignments in Phabricator. Previously, the RFC would frequently be assigned to person writing the RFC. As we try out the Rust model (per T123606 https://phabricator.wikimedia.org/T123606), and as we try to increase the speed by which RFCs move though the process, we thought it would make sense to also assign RFCs to shepherds on the ArchCom.
We didn't discuss all of the implications of this in the meeting today, but we think this might help us scale our RFC triage process. What do you all think?
I guess https://www.mediawiki.org/wiki/Requests_for_comment/Governance tries to answer the question "what's a shepherd?"
- Nominate a shepherd from a (sub)team to guide an RFC through the process.
** Makes sure that stakeholders are informed. ** Guides the discussion. ** Once the discussion plateaus or stalls & in coordination with the RFC author(s), announces and widely publicizes a "Final Comment Period", which is one week.
I'm still not really sure what any of this means. The biggest focus seems to be on speed and throughput for the RFC process itself, when the focus should actually be code quality, sustainability, and overall architecture.
I found the recent RFC discussion about adding an expiration field to the watchlist table to be very disappointing. My impression was that people were more concerned with quickly pushing through a new feature (with unknown user interface implications) than with solving the deeper underlying problems we have with page lists.
MZMcBride
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Feb 4, 2016 at 7:08 AM, MZMcBride z@mzmcbride.com wrote:
I'm still not really sure what [the "shepherd" definition in the Governance RFC https://www.mediawiki.org/wiki/Requests_for_comment/Governance] means. The biggest focus seems to be on speed and throughput for the RFC process itself, when the focus should actually be code quality, sustainability, and overall architecture.
Are code quality, sustainability, overall architecture, and speed+throughput for the RFC process mutually exclusive?
I filed T125865: Assign RFCs to ArchCom shepherds https://phabricator.wikimedia.org/T125865 which I think will be the most organized place to discuss this further.
Rob
wikitech-l@lists.wikimedia.org