Talk:Requests for comment/Governance

Teams
The proposal is focused on teams, so I suppose this is only about WMF, not MediaWiki in general? Nemo 07:38, 19 January 2016 (UTC)
 * My reading of the proposal is that "teams" means areas of focus. Examples that spring to mind are data storage, parsing, internationalization, security, user interface, etc. The basic idea is to scale decision making by expanding the number of decision makers and letting subject matter experts and enthusiasts have more control in their areas of expertise while still having a core group of decision makers (i.e. the current ArchCom group) who oversee the entire process. --BDavis (WMF) (talk) 22:12, 20 January 2016 (UTC)
 * Yes, this is also my understanding. I don't think there's any implication these people need to have the same employer.  In Rust (which this is based on), their equivalent of ArchCom is also a team, called the core team.  They say it has "some people working full-time on Rust, some volunteers, and some production users".  I assume the same holds true for the other teams. Mattflaschen-WMF (talk) 02:43, 21 January 2016 (UTC)
 * Well, this must be clarified. "Team" is not used with this meaning in MediaWiki and some current sentences make little sense, for instance "the (sub)team decides" and "creating sub-teams" (areas of focus don't decide, nor are created centrally).
 * What would those areas of focus be? Is this a proposal to make the "core team" appoint maintainers for each MediaWiki component? Which components or group of components listed at Developers/Maintainers would be affected? The proposal currently reads "a member of the core team as its team leader", so the "core team" should first be expanded to contain all self-proclaimed leaders of each group of maintainers for each involved component. Nemo 08:12, 21 January 2016 (UTC)


 * Nemo, the scoping of sub-teams (or working groups) tends to be broader than per software component. A team / working group should have a clear vision and mandate to solve a specific problem / drive an area. The scope often spans several components or services, and should ideally not overlap with other teams.
 * As Brian and Matt said, team membership is intended to be inclusive and not limited to WMF employees. One of the goals is to improve stakeholder involvement, and I think more focused teams open to all members of the community can help with that. -- Gabriel Wicke (GWicke) (talk) 18:17, 21 January 2016 (UTC)


 * Re broader, I said "or group of components". I maintain what I said above. Nemo 18:20, 21 January 2016 (UTC)


 * @Nemo, I think we agree on this subject. See T123606#1980628.  I'm hoping to define subgroups in the areas from WikiDev16 (per T124504).  Given that the Front End Standards Group is already effectively operating as a model subgroup, I'm hoping we can codify the autonomy that they already enjoy, while mentoring them on gaining broader consensus for their work. — Preceding unsigned comment added by RobLa-WMF (talk • contribs) 02:01, 29 January 2016 (UTC)
 * Those areas seem uninteresting and poorly defined hence non-functional for a RfC subdivision. I still have no idea what your purpose is. If this is the old problem of the architecture committee not being interested in certain specific topics where some hyper-active RfC proponents need architectural authority to sanction their pet projects, surely it's possible to just appoint delegates for those areas? Nemo 07:36, 29 January 2016 (UTC)

Discussion of record in T123606
Comments made on this page will likely be address, and this is a good place to make casual observations. However, I'm going to have a lot easier time keeping track of the conversation in T123606, so if you have critical observations to make, please make them there. Thanks! -- RobLa-WMF (talk) 00:27, 12 February 2016 (UTC)