Talk:Global rights

Userrights

Something that I think needs to be dealt with is that we have several "types" of user-rights. And as such, the "rules" for granting/removal may need to be specific for each "type" at the very least.

Some rights deal with the ability to "tag" or "mark a page. Such as protected, deleted, oversighted.

Some rights deal with what the user can "see", such as whether they can read pages, or view deleted pages, or checkuser information, or view software-created "groupings" of pages, such as unwatched pages or deleted pages.

Some rights deal directly with the ability to "change" something about a page. (create, edit, move, delete)

As well as things like marking an edit as minor/bot/patrolled/etc.

Some rights deal with the ability to "upload"/"import"/"export"/"move" content to (or from) a wiki from (or to) an external source (or destination).

Some rights deal with how free or restricted in access the user may be when considering the "source" of the user's input, or the current status of the user, or the current status of the target. Can the user edit from a tor node? Will the user be "autoblocked" in an IP range? Can the editor add content without the captcha prompt? Can the editor edit a protected/semi-protected page?

Some rights deal with the (potential) infringement of the userrights of others, such as user blocking, and remove userrights, and possibly page deletion (the userright to read a page).

And some rights deal with the granting of other userrights, such as create account and makesysop.

And these are just a few "general" groupings.

Roughly, to: grant access, restrict access, or remove access. Or a bit more specifically, the variously defined abilities to: view information, edit information, import/export information, move pages/edits/users, or tag pages/edits/users.

And I think all would agree that there is a difference between being able to view an article, and being able to view checkuser data. (In other words, granting CU would be to "grant access" to "view information" concerning checkuser data by "tagging the user".)

I think that the userrights should be organised in a way such that stewards would have some sort of "guide" for granting/restricting/removing userrights.

And, of course, the "global" aspect of each of these potentially increases the need for such a guide.

I hope this helps. - Jc37 03:59, 24 June 2008 (UTC)

Defining opting-in and opting-out policy

It would be useful if we define the global opting-in and opting-out policy for global policies. At the Talk:Global sysops I proposed the next: --Millosh 09:35, 25 June 2008 (UTC)

I think that it would be good to define a way how to opt-out (for smaller communities). Procedure for the CheckUser election seems almost ideal to me and I think that it should be implemented here like: "The community may opt-out if at least 30 active contributors ["active contributor" should be defined] voted in favor of the opting-out in the proportion defined by local policies for the qualified majority (it may vary between simple majority up to 85% majority) for the most important community decisions (like defining important new policies is). If such policy doesn't exist, majority of 80% would be needed for technically opting-out. The same procedure is needed for any large project for opting-in by policy." --Millosh 09:35, 25 June 2008 (UTC)

I think that is probably fine. Avruch 13:19, 25 June 2008 (UTC)

Time frame

Every proposal for a global policy should have some time frame. At the foundation-l I proposed the next: --Millosh 09:42, 25 June 2008 (UTC)

• 15 days for the initial discussion. --Millosh 09:42, 25 June 2008 (UTC)
• 5 days for sending short form of the policy at all (active) projects. --Millosh 09:42, 25 June 2008 (UTC)
• 15 days for talking about a proposal at local projects. --Millosh 09:42, 25 June 2008 (UTC)
• 5 days for giving feedback from the local projects. --Millosh 09:42, 25 June 2008 (UTC)
• 15 days for additional talk at Meta. --Millosh 09:42, 25 June 2008 (UTC)
• 15 days for voting. --Millosh 09:42, 25 June 2008 (UTC)

Note: This is 70 days in total. John Vandenberg 10:16, 25 June 2008 (UTC)

John Vandenberg proposed a faster procedure: --Millosh 09:42, 25 June 2008 (UTC)

• 7 days to discuss on the meta talk page and and formulate the proposal;
• 7 days for local projects to develop a response;
• 7 days for the responses to be collated onto meta.
• (He didn't mention voting, but I suppose 15 days.) --Millosh 09:42, 25 June 2008 (UTC)

In my proposal, the elapsed time should be around 21 days. My thoughts are that during the first 7 days, the more active projects will be discussing the vague proposal, and gearing up for a local vote. At the same time, meta will be melting pot of ideas coming in from active projects, resulting in a single proposal, perhaps including multiple options. Once a firm proposal has been put forward, the local projects will be responsible for developing a single response within 7 days. In my proposal it is the communities responsibility to be aware of new proposals on meta; I expect that people within each project would have the appropriate meta pages watchlisted, and have configured their meta preferences to notify them of changes. The last 7 days are to allow those responses to filter back to meta, and for the crats and stewards to work together to determine the outcome.

If there is no consensus regarding the first proposal, the discussion should have provided the basis for a better proposal; one has taken into account issues that caused trouble the first time, and less options. A second proposal would then go through the same process. If that fails, but new opportunity for common ground appears, a third proposal could go through the same process.

Even three iterations could be squeezed into 70 days. John Vandenberg 10:16, 25 June 2008 (UTC)

Maybe it would be a good idea to use your proposal with a possibility that anyone in any phase may ask for more time for the discussion. --Millosh 10:21, 25 June 2008 (UTC)

I hope any process of this kind would be fluid, so that 'crats and stewards can adjust the schedule as required. The only aspect of my proposal that is rather important is that the wider community should not be permitted to descend on meta with force in order to send proposals into chaos and railroad the discussion. Non-english speakers should not need to read through repetitious "votes" before they can feel confident that they are up to speed and able to vote having understood all of the details. John Vandenberg 10:30, 25 June 2008 (UTC)

One more issue: It is not rational to suppose that discussion at local projects may start immediately. At least a couple of days is needed for sending the short version of the proposal to all projects. --Millosh 10:23, 25 June 2008 (UTC)

Those responsible for ensuring that the local communities do discuss the issue should be preparing for this during the initial seven days. This quick process has a built in preference for larger communities which counter-balances that the larger projects only have a single voice.

Large projects have a more difficult time trying to even understand the impact of a proposal, because more FUD is generated, and they take longer to work out what they want. However, large communities also have the ability to meet tighter timelines, as they have plenty of people willing to rise to the challenge of making sure that their project doesnt loose its voice.

If smaller projects find that the schedule is too tight, a few additional days could be added to the process. If larger projects want more time added to the process, I would be inclined to disregard them, as giving larger projects more time will only ensure that they have time to think of everything which isnt necessary. The 'crats/stewards should be responsible for bringing it all together.

John Vandenberg 10:44, 25 June 2008 (UTC)

I don't have a problem with compacting the schedule, but I do think that we should still have a vote on meta. I don't see stewards or crats (and from which projects do these crats come from?) determining consensus by viewing the response from all the various local communities. Even if you could work it you'd be using the "one project one vote" principle, which is not acceptable in my opinion. I don't think, however, that the exact process for proposals on meta with global effect needs to be outlined in this policy. Avruch 13:25, 25 June 2008 (UTC)

Responsibilities

• Proposer (one or more persons) should be responsible for keeping proposal dynamics inside of the time frame; as well as for announcing a policy proposal to all projects. --Millosh 09:48, 25 June 2008 (UTC)
• By default, local bureaucrats would be responsible for local communities feedback. If a project has admins, but not bureaucrats, admins would be responsible. Optionally, any community may elect their own person(s) responsible for writing feedback at Meta. --Millosh 09:48, 25 June 2008 (UTC)
• According to the need for taking responsibility for a proposal, proposer(s) should be listed at the proposal's page. --Millosh 10:25, 25 June 2008 (UTC)

How to vote?

According to the present discussion, there are two possible approaches for voting about global policies, with variants. It should be discussed separately, too: --Millosh 10:53, 25 June 2008 (UTC)

• Person-based: --Millosh 10:53, 25 June 2008 (UTC)
  • Every Wikimedian has right to vote (under some conditions, of course: total number of edits, recent number of edits and similar). --Millosh 10:53, 25 June 2008 (UTC)
  • Only admins (bureaucrats, checkusers, oversights, stewards) have right to vote. --Millosh 10:53, 25 June 2008 (UTC)
• Project based: --Millosh 10:53, 25 June 2008 (UTC)
  • One project one vote. --Millosh 10:53, 25 June 2008 (UTC)
  • Some way of positive discrimination of smaller projects, but not "one project one vote" principle. It was discussed earlier that it may be some kind logarithmic scale related to the number of very active contributors or similar. --Millosh 10:53, 25 June 2008 (UTC)

I'm up for person based. It doesn't look like discussion on this page is leading to any serious revisions, and I'm not seeing much dissent. What is the best method for getting more attention to this, and at what point would it make sense to request a poll? Avruch 22:53, 22 July 2008 (UTC)