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)

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)

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)