User:Dantman/MediaWiki Development Chapter

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
{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?
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
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.

General work
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
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
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
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.

Creating other software
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:
 * 1) Find a members of the development community with proposals on how to solve the issue.
 * 2) Put the proposals up in {the chapter's} system to take comments and votes from the community.
 * 3) 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
{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?
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.