The absence of a structure for organizing such groups leaves any interested parties to create their own ad hoc structures.

Is this a problem today? If a group of people want to create a working group to focus on technical documentation, centralization of gadgets... how big of a problem is this lack of governance guidelines?

Just in case it is useful: https://www.mediawiki.org/wiki/Groups (which never quite worked).

Robla seemed to view what now is called SIG as working groups that would emanate from the Architecture Committee. In fact the Front-end standards group is something like this, unofficially?

In T164551#3238049, @Qgil wrote:

Just in case it is useful: https://www.mediawiki.org/wiki/Groups (which never quite worked).

Do we know why? There are several proposals on that page, some of which generated quite a bit of interest (50 users signed up for MediaWiki Cooperation), yet none of those were submitted.

how big of a problem is this lack of governance guidelines?

Despite the title, we might end up just producing a checklist or how-to so that users know what "makes" a SIG (or however one might call it). Deciding that there is no need for a formal process would also be a step forward.

As I see it, the main problem currently is that WMF teams and projects are created continuously on mediawiki.org (and elsewhere), but many individual employees and volunteers don't know where to start from.

In T164551#3238049, @Qgil wrote:

The absence of a structure for organizing such groups leaves any interested parties to create their own ad hoc structures.

Is this a problem today? If a group of people want to create a working group to focus on technical documentation, centralization of gadgets... how big of a problem is this lack of governance guidelines?

My personal point of view is that lacking any guidance most people really would not know how to start a long lived group. They might send an email to a list or make some page on a wiki or both, but then what? How are these groups promoted? Who does one talk to if they need help? What if any oversight or blessing is needed and from whom? As @Nemo_bis points out in T164551#3238273 the ultimate answer here might just be a checklist of recommend practices. It might be a more formal process as well. Either way I think we can do better than leaving everything up to each core group of people who become interested in organizing a group.

In the SIG creation process used by Kubernetes, creating a SIG looks to be a pretty light weight process: announce on mailing list, wait for feedback, if unopposed document the SIG in the central directory and create other needed communication channels. There are however expectations for how a SIG will operate once created. These expectations include that each SIG will have a representative who interacts with the product management (PM) group.

Wikimedia does not have a direct analog for the Kubernetes PM group. TechCom is the closest thing we have, but historically its role in the process of planning and executing a roadmap for Wikimedia technical projects has been much more "advise and consent" than the Kubernetes model of acting as a active organizer of the work of various SIGs to produce a unified suite of projects. I do like the accountability aspect of the Kubernetes model. I think that for Wikimedia the SIG creation process should be lightweight, but I'd like it to include some sort of periodic reporting component to someone. Seeing signs of life (or the lack of same) in a SIG should help people determine if joining the SIGs work would be worthwhile.

Just in case it is useful: https://www.mediawiki.org/wiki/Groups (which never quite worked).

I've been at the Foundation for almost 4 years and I don't think I've seen that page or even heard of the concept before. I have heard of MW Farmers before, but mostly because a sub-set of that group bid for the last release management contract. It seems they are organized under AffCom rather than some technical body.

Robla seemed to view what now is called SIG as working groups that would emanate from the Architecture Committee. In fact the Front-end standards group is something like this, unofficially?

My personal reading of T123606: RFC: Implement ArchCom-affiliated working groups (process inspired by Rust's "subteams") shows it to be more of potential plan to scale TechCom to a larger decision making group than the current core than a plan to support groups of people interested in topics like:

• T129842: Launch the Wikimedia Code Review Working Group
• T156301: Create a developer documentation special interest group
• Building and delivering software at WMF

A full top to bottom revamp of MediaWiki/Wikimedia's FLOSS project governance structure is certainly outside the scope of what I have imagined for a SIG process. It would however be potentially useful for Wikimedia's technical SIGs to have some avenue to seek "authority" for decision making in their chosen areas of focus. If each SIG must compose every recommendation they make as a technical RfC and see TechCom guided ratification I fear that very few recommendations will flow from such groups. Perhaps that aspect could be tabled in this initial RfC and taken up at a later date if and when we have some operational experience with SIGs and have found making meaningful change through them to be too cumbersome.

It would be useful to check https://www.mediawiki.org/wiki/Architecture_committee/Charter and clarify whether this model of Special Interest Group would be within scope of the new Technical Committee. In other words, whether we are aiming to have SIGs supporting this Technical Committee (or emanating from it, I will not get into political theory here) or whether the SIG model could work also independently from the Technical Committee, on its own, also for activities out of this committee's scope.

In any case, after reading last @bd808's comments I also think that having one model is good, and this SIG model seems to be working in other projects. I agree with the sentiment in this task that we should not get trapped in formalities and just provide the basic framework allowing people to collaborate under topic umbrellas and (ultimately, the most important goal) Get Things Done.

In T164551#3331365, @Qgil wrote:

It would be useful to check https://www.mediawiki.org/wiki/Architecture_committee/Charter and clarify whether this model of Special Interest Group would be within scope of the new Technical Committee. In other words, whether we are aiming to have SIGs supporting this Technical Committee (or emanating from it, I will not get into political theory here) or whether the SIG model could work also independently from the Technical Committee, on its own, also for activities out of this committee's scope.

The currently declared T-Comm scope leaves some wiggle room but seems to say that T-Comm may want to manage some SIGs and to avoid others (emphasis mine):

The committee has standing on questions around architecture, performance, security, database schemas, automated tests, and other technical matters.

The scope does not include developer tools, software running as Wikimedia Cloud Services (formerly "Labs"), or other non-production technologies. Nor does its scope include hardware, team methodologies (e.g. agile/scrum), code of conduct, and other social factors.

A Testing SIG would seem to fall into the declared scope (automated tests). A Core Review SIG may not (other social factors). A Documentation SIG could maybe go either way other (technical matters vs other social factors) depending on the direction taken by the SIG and the whim of T-Comm.

The best way to sort this out is probably just to take the idea to the current TechCom and ask them what they think.

In any case, after reading last @bd808's comments I also think that having one model is good, and this SIG model seems to be working in other projects. I agree with the sentiment in this task that we should not get trapped in formalities and just provide the basic framework allowing people to collaborate under topic umbrellas and (ultimately, the most important goal) Get Things Done.

I have a rough idea for a strawdog proposal on how this could all work, so I'll write that up in the task summary and we can iterate from there via edits and comments on this task and an TechCom-RFC discussion. If TechCom decides they don't want to be involved I have another idea about how we could provide a bit of support structure for the SIGs. I'll put that alternative into the strawdog proposal as well.

Should SIGs be renamed to guilds to be in line with the WMF terminology of the day?

In T164551#3333327, @Tgr wrote:

Should SIGs be renamed to guilds to be in line with the WMF terminology of the day?

I brought up this SIG proposal in the internal Foundation discussion of "guilds" (at @Tgr's prompting) and I was told that The Foundation's Guilds are not the same thing as "organized groups focused on exploring and resolving shared technical concerns". They are apparently instead intended to "create a learning environment for practitioners of a craft". I'll admit that I'm not 100% certain of the fine distinction being drawn here, but the biggest thing for me is that if they have the same name they must both be open to Foundation staff and volunteers. Having an internal Foundation organization structure and a wider Wikimedia community structure with the same name but different scopes and purposes is a repeat of the "Labs labs labs" problem.

Having an internal Foundation organization structure and a wider Wikimedia community structure with the same name but different scopes and purposes is a repeat of the "Labs labs labs" problem.

That seems like an orthogonal problem. Having a public Documentation SIG and a WMF-only Documentation Guild seems no less confusing than having a public Documentation Guild and a WMF-only Sekrit Documentation Guild, or whatnot.

The Foundation's Guilds are not the same thing as "organized groups focused on exploring and resolving shared technical concerns". They are apparently instead intended to "create a learning environment for practitioners of a craft".

That seems to suggest guilds are social things were people can chat with those with a similar interest, but won't be trusted to make decisions or anything like that. That would be pretty disappointing, but I guess this is not a good place to discuss that.

Finally a naming discussion. ;)

For what is worth, "Special Interest Group (SIG)" is a quite neutral and descriptive term that probably sounds equally neutral and descriptive when translated to other languages. "Guild" is a term charged with history and meaning (social, subjective) which is likely to be charged of history and (social, subjective) meaning in other languages, with the peculiarity that such history and meaning may change a lot across languages and people.

From the point of view of fostering an open, welcoming and diverse community, I think SIG works better than Guild.

Finally a naming discussion. ;)

Heh, quite a distraction indeed. Whoever suggested the name "guild" has read either too much or too little about medieval communes, Hansa and/or Frederick II.

If you're looking into other groups, I recommend the Foundations listserv, which is for collaborations and information sharing between free software projects: https://lists.freedesktop.org/mailman/listinfo/foundations

Directory of orgs is here: http://flossfoundations.org/foundation-directory

We have researched external movement usage of these and related structures, and compiled the most suitable aspects into this page: https://www.mediawiki.org/wiki/Special_Interest_Groups with notes on the talkpage.
The first test-case is Wiki Replicas Special Interest Group.
After 1 week of consultation feedback here, we'll announce this new group and the guidance for SIGs, on wikitech-l. Thanks again, all.

Can this be closed as resolved? Seems like https://www.mediawiki.org/wiki/Special_Interest_Groups fulfills the need.