The Wikimedia movement lacked a formal governance structure for small organized groups focused on exploring and resolving shared technical concerns. In some communities outside of the Wikimedia movement a Special Interest Group (SIG) fills this role. Per the enwiki article:
A Special Interest Group (SIG) is a community within a larger organization with a shared interest in advancing a specific area of knowledge, learning or technology where members cooperate to affect or to produce solutions within their particular field, and may communicate, meet, and organize conferences.
The absence of a structure for organizing such groups leaves any interested parties to create their own ad hoc structures. Few examples of such groups other than the Wikimedia Technical Committee and the closely related Front-end standards group can be found which have survived over the long term. Both of these groups are strongly supported by Wikimedia Foundation technical managers which may have some degree of correlation with their success. Both groups have also been granted some degree of ownership and authority in their respective areas of interest. Some other historical groups did not have clear external visibility and standards, i.e. public minutes, set meeting times, publicly declared membership. Without a governance framework it is unclear how another group interested in promoting and improving a topic like technical documentation or testing practices would be granted such authority.
After researching external communities usage of these and similar structures, we have created these basic recommendations for internal groups to organize themselves with. Note that the Wikimedia User Group model is instead recommended for groups of unlimited sizes, or wider-interests, or with other affiliate-status needs.
Special Interest Group Governance Guidance
Special Interest Groups (SIGs) are here defined as:
- Groups with publicly defined and focused scope.
- Membership can include anyone who is a demonstrated stakeholder, and the groups should be between 5-15 people.
- SIGs scope of activities generally include: discussing relevant issues, identifying problem areas, suggesting/proposing plans, creating related RfCs, overhauling specific documentation, reviewing specific areas of code, helping onboard newcomers to the area, and maintaining documentation hubs.
- SIGs must meet at least once per quarter (monthly preferred), to identify blockers and get feedback on progress. Meeting times must be published. If meetings do not occur for 6 months or 6 meetings whichever is shortest a SIG will be considered inactive.
- SIGs must publish minutes for every meeting. (e.g. Wikimedia Technical Committee/Minutes)
- SIGs must have a dedicated lead or point of contact person.
- SIGs should use relevant public communication methods such as existing IRC channels, mailing lists, and phabricator tasks, for all communication outside of the regular meetings.
Any group is welcome to add themselves, if they have satisfied and agreed to follow the guidance given here.
- Technical Debt SIG
- Front-end standards group (not formally created as a SIG, but fits the definition)
- Technical Documentation (Friends of the Docs)
- Quality Assurance SIG
- Code Health Group
- MediaWiki Docker SIG
- Kubernetes SIG
- Special Interest Group. An organization model for groups with a shared concern to meet and collaborate, ideally publicly.
- A person with either the ability to effect the item of interest or one who is effected by it to a degree that their use case has risen to prominence allowing the contribution of specific insight. This is often a SIG specific norm established by the group and lead or point of contact.
- Notes that are the written record of a meeting. They typically describe the events of the meeting and should include a list of attendees, a statement of the issues considered by the participants, and related responses or decisions for the issues.
- A regular gathering of Stakeholders who are members of a SIG that results in published minutes.