Jump to content

Talk:Global rights

From Meta, a Wikimedia project coordination wiki
This is an archived version of this page, as edited by John Vandenberg (talk | contribs) at 09:55, 25 June 2008 (→‎Time frame: fix spelling of my name, and provide links to foundation-l thread). It may differ significantly from the current version.

Latest comment: 15 years ago by Millosh in topic Responsibilities

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)Reply

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)Reply

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)Reply

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

  • 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)Reply

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)Reply
  • 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)Reply