Semantic MediaWiki development support
Semantic MediaWiki (SMW) development could use an injection of new developers/maintainers, the following is a summary of the feedback requested by Mark from the FOSS Foundations mailing list regarding encouraging new core maintainers.
Reframe the issue
RHow do we create a pipeline of new core contributors (vs. prevent existing from burnout)
- Talk to the current minor contributors and potential contributors to determine what resources would help them to be core maintainers and start mentoring others (money or otherwise).
- Do not just bring in an outside developer. Determine and solve the problems that exist first.
- Need a (1) “pot stirrer”, “glue work”, and “facilitator” (2) “communicator” (3) “technical expert”. Then try to develop a pipeline of new core contributors.
Define reasons for burnout
Define reasons for burnout: Then address/mitigate them
- Burden of responsibility: As the importance of the project increases, the weight of any “failure” increases and tends to be carried more by the core maintainers.
- Improvement 🠮 Architect the community to remove single-point failure, spread the responsibility.
- Doomed to repeat history: As the project continues, the core maintainers have to constantly remind people of project history (what has worked/not worked, what has been tried, etc.).
- Improvement 🠮 Fortunately, our product (wikis) if used properly, can help alleviate this concern by capturing project decisions and history.
- Pace of perceived competence: The need to keep contributing so the community doesn’t forget your contributions.
- Improvement 🠮 Allow maintainers to announce their releases to the community and present at events, record the releases so the community can see their impact. One caveat is the core maintainer of SMW is very insistent on maintaining their anonymity.
- I’ll sleep when I’m dead: The feeling that a break means weakness and/or giving up.
- Improvement 🠮 Promote shorter release cycles (reduce death marches). Capture requirements and direction to allow the project to be broken up into easier bits, spread out the responsibility.
- Mature = Boring: Once a project enters a mature phase, the “cool stuff” has already been done and now the only thing left is bug fixes and security updates.
- Improvement 🠮 If this is actually the case and there is a community of users who benefit from the continued updates, finding a way to pay a maintainer might be desirable.
SMW may be the tip of the iceberg
Semantic MediaWiki (SMW) is a volunteer-driven project which a number organizations use and depend on, but there is no direct compensation (yet) for any of the work done. MediaWiki is the FOSS software released by The Wikimedia Foundation (WMF) and used all over the world; from Wikipedia, to private company wikis, to NASA, to wikis on video games. MediaWiki development is run by WMF but benefits from a large community of independent developers as well, for this discussion we’ll assume they are doing well.
There are a tremendous amount of extensions (1,938 currently registered) developed for MediaWiki 3rd party use (not on Wikipedia) and not maintained by the WMF to which Semantic MediaWiki is just one, using an “app store” analogy is probably appropriate. For now the priority will be focusing on saving Semantic MediaWiki, but we should keep in mind the other extensions that might be heading in the same direction.
How do we discover what extensions are important to the community and how to support them. Of the 1,938 extensions, potentially under 200 are well maintained and actively used and less than 30 are probably critical to most users. Any thoughts on how capture and rank the canon of non-WMF supported projects and avoid the tragedy of the commons? Is it necessary to "valuate" projects? Perhaps just capturing the list of enterprise essential non-WMF extensions is a start? (e.g. SMW, translatewiki.net, Meza, Cargo, etc.)