User:Dantman/MediaWiki Development Chapter
 | Personal background on this: I've been wanting to switch to near full-time development of MediaWiki for awhile. Some time ago I tried writing up a page over the idea of a MediaWiki Foundation. However due to the focus on defining it abstractly and listing the existing ideas and rationale behind it the plan didn't go very far. Eventually I decided I would just set up a one man non-profit to do this myself so I could start without having to worry about waiting for anyone else to setup a foundation. After some irc discussions I was swayed to instead take my plans on how I'd do this myself and expand it to fit other people and make it one solid way of running the organization. The idea of a chapter came from p858snake. Daniel Friesen (Dantman) (talk) |
 | This page documents an organization which does not currently exist. This page is written in the hopes that the organization will come into existence and parts of the text may be written as if the organization did. Discussion on the creation of this organization is available on the talkpage. |
 | The name "MediaWiki Development Chapter" is used under an assumption that this will be run as a Wikimedia chapter. The name can be thought of as a placeholder in case another way of running the organization is needed. Various parts of the page text are wrapped in {single curly braces} to indicate pieces of text that may be replaced in the future with different names, terms, etc... |
The {MediaWiki Development Chapter} is a {not for profit} organization dedicated to the development of the MediaWiki software and anything of benefit to its community. The goal of the {MediaWiki Development Chapter} is not to supplant any part of the Wikimedia Foundation's activities or role on MediaWiki but instead to provide support to areas of MediaWiki which there is currently no organization supporting. It is also intended to be friendly to the current MediaWiki development community. Providing an environment for people it hires suited for previous volunteers who already understand MediaWiki and already work on stuff beneficial to the MediaWiki community without needing the company to dictate exactly what needs to be worked on. And encouraging participation inside the community similar to when they were just volunteers.
The {MediaWiki Development Chapter} may hire members of the MediaWiki volunteer community as employees to allow them to do their work on MediaWiki related projects full time. {The chapter} may pay interested volunteers within the MediaWiki community as contractors to develop features that the general community is interested in. And {the chapter} may take on development projects beneficial to MediaWiki's development community that the general community would like to see done but are not directly part of MediaWiki, are too large for volunteers to robustly finish, and the WMF is not interested in building and maintaining but volunteers are. Such as building a new bugtracker or code review system better fitted to the development community. {The chapter} may also assist in supporting and maintaining new tools and sites which are useful to the MediaWiki community but may have issues staying up on their own.
Funding
[edit]{The chapter} may receive some funds as grants and/or donations from the WMF but its primary funding should be donations directly made to {the chapter} itself. WMF's goals are broad and do not really cover general purpose development to MediaWiki. There should be enough room for both organizations to accept donations without competing for money that could go to the other. There will be people who simply want to provide money to permit full-time development of the MediaWiki software who will now be able to donate to {the chapter} instead of donating to the WMF and hoping at least some of that goes to general improvements in MediaWiki. But there will always be people who want to support free and open knowledge and will donate to the WMF. And of course there will be people interested in both who may simply donate to both organizations.
{The chapter} may also take large direct funding for individual projects from 3rd party companies interested in the development of features that will result from the finishing of that project. Though these companies are also encouraged to make normal donations to support {chapter} developers fixing general bugs in the software that they use.
Charity or not?
[edit]While the chapter will always be "not for profit" it's debatable whether it should be registered as a tax-exempt charity.
Cons to being a charity:
- {The chapter} may be limited in it's ability to try out for-profit style methods of supporting the MediaWiki community such as commercial support or paid wiki hosting.
- Tax-exempt/charitable organizations generally have more restrictions on them and extra paperwork and responsibilities in how things are managed. Which may be an excessive burden for a small new {chapter}.
- Not a con per-se. But it's possible the organization might not even be eligible for tax-exempt/charitable status. It would be beneficial to plan how to run the organization as one without this status from the very start. Perhaps using a fiscal sponsor for things such as grants and responsibly handling the few parts of the organization that do use this money.
Cons to not being a charity:
- Donations made to {the chapter} will be taxable and the organization will have to deal with extra taxes.
- May be ineligible as a WMF chapter and have to organize a different way.
- {The chapter} may be ineligible for some grants or may at least need to mange grant money separately from the rest of the funding it receives.
Questions:
- What is not for profit vs. charity law like in the US? Is there a con that should be added to the not being a charity list? Here in Canada the NFP act governs "Not for profit" companies and being a tax exempt charity is a separate registration you can optionally go through later. This means that even when being a taxable company a NFP is still liable and obligated to follow it's bylaws so you can still trust it to follow the will of it's members. What is the law like in regards to this in the US?
- What is the tax-exempt/charity law eligibility like in the us? The goal of MediaWiki development isn't as socially beneficial as the lofty goals the WMF has. Is a not for profit dedicated to MW development even eligible for this status in the first place? Skimming the stuff in Canadian law I'd almost doubt it would be up here.
Website
[edit]On {the chapter's} website a system for listing projects and tasks will be maintained. This system will allow individual projects and tasks to be added as individual entries. These may small code ideas, simple references to bugs in Bugzilla that can be fixed, rewrite ideas, whole large development projects, et cetera. The goal of the system is to gauge community interest. The entry may be commented and voted on by the general community.
Developers in {the chapter} may put up entries for projects they are interested in working on. And the general community may put up entries for things they'd like to see worked on by {the chapter's} developers. Developers should add themselves to any entry they are interested in working on and are encouraged to prioritize projects that have high community interest. The system may give lower importance to — and in some areas ignore — projects that no {chapter} developers have added themselves to. Essentially acting as a non-fixed veto indicating there are no developers currently part of {the chapter} who consider the entry within their skilled area to work on it. Until someone new comes along with the skills to do it.
{Chapter} developers' activities
[edit]General work
[edit]The primary activities of {chapter} developers includes working on projects listed in {the chapter's} website, finding small reported bugs and fixing them, as well as small extra tasks such as providing support in #mediawiki, participating in code review of areas of our codebase they are familiar with.
Most of these tasks may be short and overlap each other. And hence cannot be time-tracked very well. For a former volunteer already with an interest in the topic, sometimes time-tracking can also deter them from doing some work in narrow time periods they would otherwise have done something productive as a volunteer. Hence importance is not place on the time-tracking of general work. Instead developers are encouraged to keep some sort of public diary, blog, micro-blog, et cetera on their daily development activities to keep them in touch with the community over what they're working on.
Fixed projects
[edit]Some of a {chapter} developer's work may involve more structured projects they dedicate more time to than to general work. Some of these projects may come out of {the chapter's} website while some others may be brought up by 3rd party companies willing to support the creation of a general feature.
Organization structure
[edit]Volunteers hired by {the chapter} are generally self-directed enough that a strong vertical structure would not help and instead potentially hinder their work. {The chapter's} broad dedication is also not well suited to having a management directing the developers. Hence {the chapter} will take a flat/horizontal structure. Developers can direct themselves to make the best use of their time based on their experience as volunteers and what the community is interesting in seeing done.
Hiring new developers
[edit]As a flat company the method of hiring new employees may develop over time. However the volunteer/wiki community this chapter is based on already has a model that would likely work out as a method of hiring new developers; We already have communities deciding admins, bureaucrats, and bots with RfAs, RfBs, and bot requests for approval. Determining decisions to various things with RfCs. Requesting mediation with RfMs. Deciding on deletion of pages with RfDs/AfDs. Requesting new wiki languages with "Requests for new languages". et cetera. Using a similar model for new developers would likely fit very well into the structure of the company. Start a "Requests for employment" wiki page for a known volunteer developer. Then start discussing it with other {chapter} developers and members of the volunteer development community. How experienced in MediaWiki development is this person? Can this person self-direct themselves within {the chapter's} structure? et cetera. Then it can be taken over by someone within {the chapter} capable of filling out the necessary paperwork.
Interested parties
[edit]I'm Daniel Friesen also known by the nicknames Dantman or Nadir Seen Fire on wikis, irc, etc... I've been part of the MediaWiki volunteer community for several years. I've committed many svn commits, made many changesets to core and extensions, and made some extensions of my own (a little harder to link to a list of). I continually write down code ideas on improving MediaWiki. Some of my larger ideas are written down on other wiki and RFC pages like my skinning system plans, RFCs on dropping actions in favour of page views and special pages, entrypoint routing and 404 handling, ResourceLoader CSS Extensions, abstract table definitions, updating our code to use RDFa 1.1 instead of RDFa 1.0, and dropping XHTML 1.0. At one point my current employer Redwerks also let me do some specific MediaWiki projects during work time which allowed me to write the skinning tutorial, subskin tutorial, and the Short URL builder.
I've been wanting to switch to near full-time development of MediaWiki for awhile. Plenty of the things I try to or want to do seem to be desired by members of the community. But that list of code ideas practically ends up becoming a black hole because while I have the skill for these projects and more I never have the time to finish a notable amount of them or any of the larger MediaWiki improvement projects I could be working on.
My work lately has been mostly things like taking mockups and turning them into themes and skins for clients. Pretty much the bulk of time being spent repetitively tweaking CSS properties switching back and forth between mockups, sites, and theme files to make the output look like the mockup instead of actually using my programming skills. This kind of work leaves me mentally exhausted as the actual work doesn't use my developer skills and instead requires me to keep design in my head, something on the outskirts of my skill-set. So after the trouble this gives me to work hours as well as other issues I barely have any time for MediaWiki development nowadays. And when I do I naturally end up doing some small changes I'm interested in rather than tackling a pile of bugs and larger projects to seriously improve MediaWiki due to lack of time to do something serious.
I'm fairly entrenched with my current employer, it would probably be hard on them for me to suddenly leave. But they only really need me for server stuff, some occasional project, etc... So I expect migrating to a slowly growing {MediaWiki Development Chapter} would work fairly well; Continue at my current employer as {the chapter} starts up. Switching to working for {the chapter} for short terms (working for 2 weeks at {the chapter} then returning would probably work well) as the chapter has the funds to employ me. Then — as {the chapter} grows into a full organization capable of employing multiple members of the MediaWiki development community — changing to only helping my current employer part-time and working nearly full-time on MediaWiki development as a member of {the chapter}.
I'm Canadian so assuming we do incorporate this in the US I won't be able to serve as the primary director, so other people will need to be involved in the initial creation of {the chapter}.
When {the chapter} is created I'm willing to write the system needed for {the chapter's} website. Once that's done I have a number of projects I've thought of or partially worked on that I'd happily add to the list on the site and work on whichever ones the community is interested in (well, in addition to shuffling through bug reports for things to fix, etc...):
- Short URLs: I have an ongoing project on short URLs I could continue.
- Continue testing different types of webservers and coming up with the best ways to do short url config in them.
- Write the nginx and lighttpd manuals with the rules that are already in the short URL builder and other manual pages when other webserver patterns have been determined.
- Eventually write a built-in short URL config tool for the MediaWiki installer.
- Gareth: If the community is interested in it I'd be happy to seriously continue working on making Gareth — the idea I had for a user friendly Git code review system fully functional: User:Dantman/CodeReviewSystem, http://gareth-review.com/
- Skinning system: It's a long project but if the community is interested in my ideas for the skinning system I'd be willing to slowly continue implementing it (though perhaps after a break working on other MediaWiki projects; I've already seen enough skin and theme related code lately).
- Password rewrite: I have a near-finished branch of code improving our password storage system and the methods we use of securing those passwords. I'd be happy to finish it up and get it into core.
- Namespace handling: I have some partial code from when I tried starting to fix bug 31063 [MediaWiki should use a reservation system for namespaces] by implementing namespaces in the database, registration, and a UI for it. I'd be happy to dig that up and continue working on it.
- Page deletion: It's not my RFC but I find the idea of a table for deleted pages to improve the performance and UI of our page deletion code so I'd love to implement it.
- Other large project RFCs like dropping actions in favour of page views and special pages (PageView stuff) and entrypoint routing and 404 handling I'd be happy to continue working on if the community is interested. Really you can add any RFC I've written to the site and I'd be happy to work on it.
- I'd like to have PageView done first, but I'd be willing to implement some other stuff that has been discussed like OpenGraph support built into core and outputting proper descriptions of pages for search engines, share features, etc... to pick up on.
- ...
That's just a list of stuff I can think of right now. My code ideas page continually gets new ideas added to it and I'd be happy to work on just about any of the ones that could still be considered serious. Things like the abstract revision system and a built-in mass-replace tool are there too. And I continually find new bugs in bugzilla I'm interested in fixing.
Extra notes
[edit]Creating other software
[edit]One of {the chapter} goals is to make it possible to solve problems the community has like "This bugtracker does not fit the community." and "Our code review system is counter-intuitive and unfriendly towards the community and we can't find something better." by making technical solutions possible which previously couldn't be done. Such as making the creation and maintaining of a dedicated piece of software — when the WMF doesn't want to expend time maintaining a brand new system — by letting someone within {the chapter} take on the project and maintain it.
The basic process for this is:
- Find a members of the development community with proposals on how to solve the issue.
- Put the proposals up in {the chapter's} system to take comments and votes from the community.
- When a proposal has high community interest {the chapter} hires the volunteer or someone capable of carrying out the proposal to work on its development.
Relation between {the chapter} and WMF on existing MediaWiki development projects WMF employees are working on
[edit]{The chapter} does not exist to take over any project that the WMF is already working on. Projects being worked on by WMF employees will remain as-is as long as the WMF wishes to continue working on the project.
In the event that the WMF wishes to drop a project beneficial to the community {the chapter} may take on the project provided there are {chapter} developers willing to work on it or volunteers willing to be hired to work on it.
Who is going to do tarball releases of MediaWiki core?
[edit]Creation of {the chapter} will not directly affect how new releases of the MediaWiki software are done. Unless the volunteers who are currently doing release management wish to become {chapter} developers and do the release management as part of their full-time job. The hardware for these releases will also remain with WMF for the notable future as long as no-one has a better idea for their management.
{The chapter} in relation to chapters like WMDE
[edit]Some large chapters like WMDE engage in MediaWiki development projects of their own. Most of these projects are projects that that chapter finds important and are focused on Wikimedia wikis like the foundation's own projects. The {MediaWiki Development Chapter's} relation with large chapters like WMDE over MediaWiki development is roughly similar to it's relation with the WMF on MediaWiki development; {The chapter} has no plans to take over projects already being taken on by large chapters like WMDE.