User:MF-Warburg/SisProjCom draft

A personal proposal based on the discussions that already took place about the Sister Projects Committee. --MF-W 17:34, 18 April 2012 (UTC) See also:

• Sister Projects Committee/Draft charter
• New project process

which have content which was merged to them from here. --MF-W 16:16, 27 April 2012 (UTC)

Sister Projects Committee Charter/Policy

The Sister Projects Committee (SPCom) is a community committee that is responsible for developing policies and documentation for creating and reviewing sister projects (see definition below).

Our scope includes supporting and coordinating new project proposals, adopting non-Wikimedia projects, and also reviewing and supporting the existing sister projects (including requests to close/merge/spin-off existing sister projects, and monitoring the needs and priority bugs of existing sister projects).

Simply said:

• 1) approving new WMF projects, either from scratch or by accepting an already existing project as WMF project
• 2) how can existing projects be supported
• 3) how projects can be merged together

The scope

Responsibilities of the Committee

The Committee has the ability to: (per the proposals that are drafted in the sections below)

• recommend that a new sister project be created or adopted,
• recommend that existing sister projects be merged (under the Closing Projects Policy however, even if that sounds paradox), or that a sister project and an external project be merged,
• recommend that an existing sister project be closed,
• review proposals for new projects, help them through the proposal process, and recommend trial versions on the Wikimedia Incubator or other appropriate wikis.

Recomendations are made to the Wikimedia Board and the communities of the projects in question.

The committee's scope does not overlap that of the Language committee; SPCom recommends approval or closing of sister projects as a whole, not specific language editions of existing sister projects. It will engage and defer to the Language committee on issues concerning language or linguistics.

Definitions

Sister projects include wikis hosted by the Wikimedia Foundation where community members have been active. This includes the wikis listed at wikimedia.org.

Organization of the committee

Membership

The committee will comprise community members that represent

• all of the sister projects,
• linguistic diversity,
• a broad range of talents, experience and professional background

Every member should be active on meta/strategywiki in categorizing and reviewing new proposals, or active on at least two different free-knowledge wikis, whether Wikimedia projects or other.

An interim committee will be appointed by our Board liaison to finalize the committee charter and start work. The first full-term committee members, and ongoing membership process, will be proposed along with the charter for approval by the Board.

Once the committee is active, the following will rules will apply: People who want to become a member can make an application to join the committee, which will then be reviewed and voted on by the existing committee members. Members who are inactive across the Wikimedia Foundation projects for a period of more than 3 months will be sent a courtesy email to let them know that their membership will be ended unless their participation is renewed.

Observers are Wikimedians who are given access to any private communication channels and collaboration spaces [if there will be any]. People who wish to become an Observer may apply to the committee.

Chair

• The committee's chairperson will be elected for a term of one year by the committee itself. The chair is responsible for TO BE DISCUSSED (so far, only voting - see below).
• A two-thirds majority is required to reelect the current chair.
• A two-thirds majority is required to change the chair.
• The chairperson may appoint a deputy chair to ensure continuity in the absence of the Chair, e.g. when the Chair is travelling.

Decisions

• The committee will discuss all its decisions on its own mailing list to which only committee members can write e-mails; other users only if their mail is accepted by a list admin. The list archive itself however is open for everyone to read.
• The committee should always strive to reach a consensus for its decisions, but if no consensus can be found, the chairperson should initiate a voting, in which decisions are taken by a simple majority vote (i.e. more votes in favour of a decision than against), except if a higher majority is required.

Members may be excluded temporarily from Committee decision-making if they have a major conflict of interest regarding a particular project.

ad 1: New Projects Policy

Introduction

This policy is intended to define a clear process of how one can propose new projects to be hosted by WMF.

As with the LPP and CPP, all current proposals for new projects are made invalid, though they may be immediately "re-opened" (remember that so far they have received little attention anyway) according to this policy. This serves two purposes: 1) no sudden workload for the community and SPCom 2) only proposals with active interested users have a chance.

The policy gives a lot of room to the committee for considerations, alterations of the proposed things etc. This is done on purpose (and perhaps not even made clear enough below). The committee should be able to find the best possible solution for any proposed project.

The process

Any user can make a proposal for a new project.

• Type N(ew) -> #Entirely new project
• Type E(xisting) -> #Integrate an Existing Project

In the event that a SPCom member considers a proposal harmful, with no reasonable possibility of a positive decision, the member may close the discussion immediately. This may be appealed to the closing member or to another member of SPCom, who may re-open it if that member finds the discussion to be of value. Any other responsible WMF user, not affiliated with the proposal, may also close a discussion considered disruptive, for stated cause, pending review, and it should not be re-opened except by a SPCom member.

Entirely new project

1. A proposal must include the following info:
   • (tbd; a template for easier making proposals will be made).
2. A proposal is then open for at least 30 (tbd) days for comments and questions from the community and committee members. Everyone is welcome to comment on the proposal and encouraged to discuss whether it is a good idea to open such a new project.

   However, this is not a vote. The project will be assessed on its linguistic (insert a fitting word here, the sentence was copied from LPP) merits and chances of flourishing. Even if there is strong support, the proposal may be denied if there are strong arguments against its creation and insufficiently strong arguments in support as judged by the Sister Projects Committee.

3. After that, SPCom decides within 1-2 weeks if the proposed project is viable as a Wikimedia foundation project in general. If not, the proposal can only be resubmitted if considerably altered, or after some time. If appropriate, SPCom will give specific recommendations for improvement, or suggestions for where else the project might find hosting/support.
4. If yes, a trial/demo/whatever version should be opened in the Incubator or elsewhere.
5. The committee will watch the developments around the proposal (i.e. activity on the demo version + comments on the proposal page on Meta) closely and, at latest after one year, will evaluate the success of the trial version, recommend its approval as a new Wikimedia Foundation project, to close it, or to formulate targets it needs to achieve to be reconsidered.
6. A recommendation to approve a proposal as a new Wikimedia Foundation project goes to the Board of Trustees, which has the final say.

To be considered throughout the process:

• The committee can also recommend to integrate a proposal into one of the existing projects.
• The committee needs to see if there would be side-effects on existing projects.
• The committee should readily listen to community comments at any stage of the process.

Integrate an Existing Project

1. A proposal must include the following info:
   • (tbd; a template for easier making proposals will be made).
2. A proposal is then open for at least 30 (tbd) days for comments and questions from the community of Wikimedia projects and the community of the affected existing non-WMF project and committee members. Everyone is welcome to comment on the proposal and encouraged to discuss whether (and in which way) it is a good idea to integrate the project. However, this is not a vote. The project will be assessed on its linguistic (insert a fitting word here, the sentence was copied from LPP) merits and chances of flourishing. Even if there is strong support, the proposal may be denied if there are strong arguments against its creation and insufficiently strong arguments in support as judged by the Sister Projects Committee.
3. If the community from the existing non-WMF project makes clear that they don't want to become a WMF project, such a proposal will be outright rejected.
4. After that, SPCom decides within 1-2 weeks if the proposed project is viable as a WMF project. If not, the proposal can only be resubmitted if considerably altered, or after some time. If appropriate, SPCom will give specific recommendations for improvement.
5. If SPCom thinks a proposal to make a non-WMF wiki a WMF project should be accepted, a recommendation to that effect goes to the Board of Trustees, which has the final say.

To be considered throughout the process:

• The committee can also recommend to integrate a proposal into one of the existing WMF projects.
• The committee needs to see if there would be side-effects on existing projects.
• The committee should readily listen to community comments at any stage of the process.

Recommendations

Per above, SPCom would also be able to make other recommendations apart from those mentioned above which would be sent to the Board for approval. These should be redirected to the relevant wikis / their communities for consideration.

SPCom will help in the implementation of its recommendations as far as possible.

ad 2: Supporting existing sister projects

Existing projects deserve regular publicity and attention. They are encouraged to reflect on what they need in terms of community or software tools, and to publish ideas and needs for growth at least once a year.

The Committee can serve as a point of contact with the WMF for issues facing sister projects, to communicate those issues well and put them in context.

ad 3: Proposed changes in CPP

• A new type of proposal is introduced: type 3 – non-language subdomain projects, i.e. general "meta" and planning wikis. Langcom is not responsible for these proposals anymore, but the Sister Projects Committee is. The process stays the same.
• The Proposals for closing projects process may then be used to conduct the suggested merger of Meta, Outreach, Strategy etc. in the following form:
  • Proposal – Community discussion – Committee discussion/decision – Board approves
  • Proposed action: Closure, not deletion (see also below)
  • Proposed action regarding the content = Move to Meta
  • => Actually, this is the typical kind of type 1 proposal, just with a Move to Meta, instead of Incubator.

Note: Some technical concerns were given. I propose to use (and assume that it will be used) the Import from file (importupload) method – I ask everyone who had the concerns to have a look at the pages of Lezgi Wikipedia, which recently left Incubator, at incubator:Special:Prefixindex/Wp/lez and lez:. The pages were imported with their full history from Incubator to lez.wp, and on Incubator, a note is left behind (try to edit them!). On Incubator, the pages will eventually be deleted; on Strategy and Outreach, they could be left in place (closure, not deletion). Additionally developers will need to devote time, where requested by the Committee, for resolving the problems that exist with renaming wikis so that the current long-awaited renames can finally be conducted AND that a possibly decided rename of Meta (incl. Strategy, Outreach) can be conducted (see bugzilla:19986).

Renaming a wiki, if not for linguistical reasons (i.e. changing the ISO 639 code), will be a special responsibility of the Sister Projects Committee.

Policy for the closure of entire sister projects

only a rough outline for the start.

1. A proposal is brought up. If it does not give severe reasons, it is invalid.
2. The proposal (and its reasoning) are discussed by the community + the committee for at least two months
3. For the case of acceptance of the proposal, it needs to be determined what would happen to the content of all the language versions of the project.
4. ...
5. In the end, the committee determines whether it recommends the closure of the sister project to the Board or not.
6. The Board has the final authority.