UCOC Ratification Proposal

This page attempts to set out a few hopefully non-controversial general principles, as well as my own specific proposal and accompanying reasoning

General Principles

There are general aspects of any ratification proposal for the Universal Code of Conduct (UCOC) which would need settling, including:

1. Which groups must agree for ratification to be completed? (Potential examples include: WMF Board, local projects, majority of active membership, affiliates, chapters/thematic groups)
2. Will ratification be "as a whole" or "by article"? In the event of a by-article ratification, what happens if a clause is rejected?
3. Methodology of ratification (e.g. voting system, timeline, eligibility criteria, can members active on more than one project vote more than once?)

Proposal Reasoning

Utilising these multiple viable ratification proposals can be created. In order to create my one below I focused on a method that would remove the most causes for concern that have been raised along the way. Key amongst these include:

1. Lack of trust between Community & WMF
2. A combination of lack of trust and wildly different needs between small, medium, and large communities
3. Certain communities having specific concerns about specific parts of the UCOC and specific proposals of the enforcement mechanism(s) while not necessarily being opposed to a UCOC in general.

Proposal I added to UCOC draft

1) “Who gets a say?” – voting groups (VGs) I’m going to use the term “voting groups” for which a sufficient majority of each is needed in order to ratify the UCOC:

1. VG1 – local projects (e.g. en-wikipedia, fr-wikinews)
2. VG2 – active editors across all projects
3. VG3 – recognised affiliates
4. VG4 – WMF Board of Trustees

2) What are we getting a say on? Talks with members of the drafting committee have indicated that by-section ratification comes with significant issues that may outweigh its positives. As such, I believe dividing just once, with a ratification vote on each, is the best route:

1. Content of the UCOC “Phase 1”
2. Enforcement of the UCOC “Phase 2”

3) Methodology This is a set of critical details and a bunch of small ones. Some are like “should every local project count, or just those with 5+ active editors?”, is a sufficient majority of a VG 50%+1, or more? What definition of an active editor are we using?

They’re important, but can be settled once the first two questions have been.

Reasoning

1) These are the core groups who get affected by the UCOC. All will go through significant change. But the logical question is why I’ve separated VG1 and VG2 – after all, projects would go like how their editors supported. That’s true, and for a single local project is enough. But en-wiki has a huge % of the total editor base, but is just one project. Projects with fewer than 100 editors make up a huge % of all local projects. If just editors counted, small and medium projects would be disenfranchised. If just local-projects, huge numbers of editors at a couple of large projects would be. Neither is acceptable

2) The reasoning for not doing by-article is included, but I’ll gladly discuss with anyone with an interest (pro or anti). However, that “Phase 1” is key. Phase 1 never received community-wide consensus of any type. As such, multiple editors have raised a valid concern that it has no mandate. If its supporters think it is good as it is written then why should a separate ratification vote be an issue?

Do you support its inclusion? Yes? Then Defend It.

Phase 1 gave most communities less time than they should have, failed to answer questions raised, and continued to include strange points (for example, “introducing bias or incorrect information” has somehow become a UCOC violation every one of us is guilty of).

3) Methodology includes things that absolutely need to be settled before we get the ball rolling on any actual process or even process discussion, but would be good for a month’s time if we’ve settled down on ratification ideas and preferences.

Proposal 1

1. Positive clear consent of a majority of the following 3 "voting groups" must be acquired for the UCOC to take effect: local projects (e.g. en-wikipedia, fr-wikinews); active editors as represented by the local projects (note: could instead be Steward-elector eligible editors?); the WMF Board.

2. "Active editors as represented by the local projects" will be counted as the number of active users (example) on a local project in last full month prior to ratification commencing. If a local project assents, then all its active users will be included as in favour, if it dissents then all will be included as opposed.

3. Ratification is to commence no earlier than 1 month after a final draft version is made publicly available and translated into the languages of at least the ten largest projects. Each ratification voting stage is to last at 1 month.

4. Stage 1 will consist of a "by-article" set-up, with each being individually possible to support/oppose/abstain. The WMF Board may choose to vote on the UCOC as a whole (or not) as it sees fit. In the event of all articles passing, then the UCOC is automatically passed. In the event of one or more articles being opposed by a majority of any of the voting parties, then either an amended version must be created (in which case ratification starts again) or an overall vote of the remaining UCOC to see whether it can pass in its amended form must be made by the voting groups.

5. Editors are eligible to vote on any project that they are auto-confirmed on and not site-blocked. Individuals may only vote on a single project, although they may select which project they vote under, so long as they meet any eligibility criteria. Scrutineers, drawn from the Stewards, may utilise the Checkuser tool to prevent sockpuppet votes. All local projects outside the Incubator are included, with the exception of meta-wiki, test-wiki, and similar. Local projects that do not participate at all will be considered to have "abstained".

Pros

• This makes it much harder for large projects to force something through that is poor for small projects and vice-versa.
• It ameliorates issues caused by projects (or affiliates linked to projects) who are better at "getting the vote out" overrunning those that are not.

Cons

• Active users is a very easy group to meet, and vulnerable to gaming. A higher standard (e.g. 30 edits in the last month) may be needed to avoid issues. I am definitely open to change on it
• It may also require some level of work to calculate this number across all local projects

Proposal 2

1. Positive clear consent of a majority of the following 3 "voting groups" must be acquired for the UCOC to take effect: local projects (e.g. en-wikipedia, fr-wikinews); eligible voting editors; the WMF Board.

2. "Voting editors" is the sum of all individual community members who vote across all projects. Eligibility will be the same as for Steward elections. Editors may only vote on a single project, but may choose which project, so long as they are autoconfirmed on it and not site-blocked.

3. Ratification is to commence no earlier than 1 month after a final draft version is made publicly available and translated into the languages of at least the ten largest projects. Each ratification voting stage is to last at 1 month.

4. Stage 1 will consist of a "by-article" set-up, with each being individually possible to support/oppose/abstain. The WMF Board may choose to vote on the UCOC as a whole as it sees fit. In the event of all articles passing, then the UCOC is automatically passed. In the event of one or more articles being opposed by a majority of any of the voting parties, then either an amended version must be created (in which case ratification starts again) or an overall vote of the remaining UCOC to see whether it can pass in its amended form must be made by the voting groups.

5. Scrutineers, drawn from the Stewards, may utilise the Checkuser tool to prevent sockpuppet votes. All local projects outside the Incubator are included, with the exception of meta-wiki, test-wiki, and similar.

Pros

• This makes it harder for large projects to force something through that is poor for small projects and vice-versa.
• Results are likely to more closely match those who have a firm interest in the topic, meaning more-affected projects will likely participate more and have more say.

Cons

• Projects may struggle to make all editors aware of the importance, either from size or from translation difficulties. Projects (or affiliates linked to specific local projects) that are more cohesive will be able to bring disproportionate impact.

What about affiliates?

• In my personal view, affiliates are easy to create, compared to Chapters/Thematic Groups or even local projects. Multiple groups have been made in the past for the primary purpose of getting an organised seat at the table, and have some significant negatives. They do, of course, also serve various positives, but a number of affiliates would be functional duplicates of local projects - either double counting, or being a real concern if they chose opposite to the local community they should be aiding.

However - I am aware that many disagree with me, and would have no great objection if people would like to add it as a fourth "voting group" in either clause 1.