Status report on this task:

• Content format (T119022) - I haven't had a chance to work with this group yet.
• Content access and APIs (T119029) - I made a comment this morning on T119029 trying to rekindle the flame there
• Collaboration (T119030) - awaiting response on T119030#1960994. I've converted this one into RFC: Collaboration working group
• Software engineering (T119032) - I haven't had a chance to work with this group yet. I vaguely recall an email or a comment somewhere, but I didn't track it on T119032 (doh!)
• User interface presentation (T119162) - I'm working with @Volker_E and @Krinkle to transition the Front End Standards group into a great example of how we hope all working groups will function.

Successful completion of T123606 likely relies on completion of this task.

I'm going to quote @Qgil and @greg from T119030, and respond.

In T119030#2015074, @greg wrote:

In T119030#2014769, @Qgil wrote:

I'd rather focus on more specialized committees created to solve a specific problem and formed by people that are clearly the experts in that scope. These committtees could be temporary or permanent, depending on their goal.

+1, I was thinking the same for the Software Engineering area/group.

Specialized temporary committees sounds great in theory, but working groups are expensive to establish norms and infrastructure for. We established the five working areas for WikiDev 16 to scale the decision-making process. Constantly forming and disbanding working groups (with presumably new names) makes it confusing for new contributors to get involved in the decision making for the area of their expertise.

In T124504#2015158, @RobLa-WMF wrote:

Specialized temporary committees sounds great in theory, but working groups are expensive to establish norms and infrastructure for. We established the five working areas for WikiDev 16 to scale the decision-making process. Constantly forming and disbanding working groups (with presumably new names) makes it confusing for new contributors to get involved in the decision making for the area of their expertise.

I don't think the working areas are the obvious entry points for people to get involved. I think people have itches (say "I want a Code of Conduct" or "I want us out of Gerrit") and they join the group working on that thing. Thus, we would need a page describing what each working group is both generally tasked with along with what projects they are actively working on (the itches/hooks).

I don't see how it'd be any harder to have a page on decision making listing currently active working groups/projects vs a page on decision making listing X number of 'always formed' working groups with a short list of things they're actively working on.

Personally, I think the overhead of having multiple 'always formed' working groups that need support/maintenance that also have sub-projects (eg: CoC) that need (different) active support is too much for our size. The way to 'trim the fat' would be to focus on the locus of action: the specific working group focused on a specific issue.

In T124504#2015213, @greg wrote:

I don't see how it'd be any harder to have a page on decision making listing currently active working groups/projects vs a page on decision making listing X number of 'always formed' working groups with a short list of things they're actively working on.

That doesn't seem to scale the ArchCom triage process though. If we need to delegate the evaluation of an RFC to a group, do we need to form the group first?

In T124504#2015241, @RobLa-WMF wrote:

That doesn't seem to scale the ArchCom triage process though. If we need to delegate the evaluation of an RFC to a group, do we need to form the group first?

By definition yes: if you want to delegate to a group, it needs to exist.

My theory is that we will get better execution if the group is formed around a specific need/objective, instead of a standing working group of people generally interested in a large set of things (eg "Software Engineering").

In T124504#2015213, @greg wrote:

I don't think the working areas are the obvious entry points for people to get involved. I think people have itches (say "I want a Code of Conduct" or "I want us out of Gerrit") and they join the group working on that thing. Thus, we would need a page describing what each working group is both generally tasked with along with what projects they are actively working on (the itches/hooks).

It seems obvious to me that the people who have itches are the RfC authors themselves and interested parties contributing to discussion of a particular RfC. A working group would be a collection of domain experts who can be trusted as stewards of the code and architecture intersecting with their domain and to provide useful feedback to RfC authors. They are a method to scale the ArchCom model without bloating the core committee with all of the expanded membership. I would expect each working group to include a core committee member.

In T124504#2015158, @RobLa-WMF wrote:

Specialized temporary committees sounds great in theory, but working groups are expensive to establish norms and infrastructure for. We established the five working areas for WikiDev 16 to scale the decision-making process. Constantly forming and disbanding working groups (with presumably new names) makes it confusing for new contributors to get involved in the decision making for the area of their expertise.

I have nothing against established working groups. I'm just questioning that "Collaboration" is the right scope for a group. Handling harassment reports, reducing code review waiting times or making mediawiki.org a great site are very different tasks that require very different skills and will receive the interest from very different people.

For what is worth, the CoC requires a permanent committee. The other two examples relate to endemic problems that we haven't solved in years. If we would solve these deep problems by "constantly forming and disbanding working groups", where can I sign? :)

About the ArchCom triage process, the topics theoretically related to the Collaboration area never have been a real problem in the ArchCom's backlog. Whenever there was something big enough to be a problem (i.e. Bugzilla migration) others took care of it. I welcome the idea of the ArchCom bringing collaboration topics within the scope (i.e. the CoC), but I expect these topics to keep being well resourced in terms of community or WMF involvement.

Working groups should be formed with a scope emphasizing the problem the group is tasked with solving. We should avoid forming working groups where the answer to the problem is baked into the charter/scope of the working group is solving. As I said in T123606, my fear is that what people really want from ArchCom is a place where we can officially bless their solution looking for problem, rather than forming working groups tasked with taking an open-minded approach to solving a problem. Every working group should be formed with a defining statement of what problem they are trying to solve.

For example, CoC requires a permanent committee (hence T126605). That said, we need to define the problem that that group is trying to solve clearly, and be open to the possibility that a written set of rules is the wrong tool for the job.

I've admired the times when an ArchCom member interrupts a long overly complicated discussion with "what problem are we trying to solve anyway?" We should all get into the practice of regularly asking ourselves that, and in particular, endeavor to take the 5 Whys approach (recursively challenging each problem statement until we hopefully get to the root cause). At each level of recursion, the scope likely increases, and we're likely to realize we need broader and deeper expertise to solve the problem well.

For ArchCom to have authority, it needs to have the trust of the Wikimedia developer community that it delegates that authority wisely. Overly narrow delegation would be disempowering, and give subteams the excuse to avoid exploring root causes (they could claim "out of scope"). ArchCom also needs to have capable subgroups to delegate review of bold new ideas to, which becomes impossible if the scope of all of the subteams is too narrow. Overly broad delegation will make it difficult for the subteam to focus, and create a situation where individuals won't be able to trust the subteam without participating in it (thus making it so that everyone needs to be part of every subteam).

WikiDev '17 is going to be awful if we don't have sufficiently broad subgroups to delegate portions of the planning to.

We discussed this in the 2016-03-16 ArchCom meeting, as each of the shepherds gave an update on things that they're shepherding (per T125865: Assign RFCs to ArchCom shepherds). In that meeting, I pointed out that it's been challenging finding owners to follow up on these sessions, let alone finding enthusiasm for creating working groups around any of these 5 areas. There seems to be tentative enthusiasm for T123606: RFC: Implement ArchCom-affiliated working groups (process inspired by Rust's "subteams"), though it's also been difficult building consensus around any viable proposal.

In T124504#2128122, @RobLa-WMF wrote:

We discussed this in the 2016-03-16 ArchCom meeting, as each of the shepherds gave an update on things that they're shepherding (per T125865: Assign RFCs to ArchCom shepherds). In that meeting, I pointed out that it's been challenging finding owners to follow up on these sessions, let alone finding enthusiasm for creating working groups around any of these 5 areas. There seems to be tentative enthusiasm for T123606: RFC: Implement ArchCom-affiliated working groups (process inspired by Rust's "subteams"), though it's also been difficult building consensus around any viable proposal.

I strongly favor organic growth over inorganic growth. If there currently isn't genuine interest in creating sub-groups/sub-teams due to lack of participants and/or lack of willing leaders (i.e., an enthusiasm gap), I think that's the system's way of saying that the idea likely isn't a good fit for our context and consequently won't work well.

From my perspective, you put forward these five topics in order to give the 2016 developer summit some focus. Fine, that's fair enough. But that means that these five sub-categories are only 2016 Wikimedia Developer Summit topics. As far as I can tell, these five topics are not correlated to any real and indefinite sub-teams that have a clear focus and agenda, they are just headlining items in a conference schedule in a particular year.

In T124504#2836510, @daniel wrote:

Got stale, we should talk about working groups in a more general context.

should all of the proposed working groups (parent tasks) be declined as well?