Author: paul

Description:
I recommend that the current system of priveleges be
changed to a type of table based upon a word in the
database as a bit-level privelege mask, or upon a
set of flags.

I understand under the current system there are
basically something like 5 or 6 levels of privelege,
something like guest, logged-in user, bureaucrat,
sysop, administrator, programmer.

I would like to recommend creation of a privelege
flag field consisting of perhaps 32 or 64 bits of
privelege, such that more fine-grained control can
be made as to what can or cannot be done. This would
allow certain features of the system to be made
available or denied depending on which flags the user
has set.

If this capacity already exists, please excuse me,
the last time I read the source code to the program I
did not notice it.

Now, the number of privelege classes doesn't have to
be 32 or 64, I just thought of that from the size of
a word or double word, which could be stored in the
database. In a program I wrote once, I created a
table of 50 different priveleges, each being a single
boolean entry.

Another possibility is to allow pages to be assigned
a minimum user level to be able to be edited directly,
or having edits by users below that level to be sent
to a person (or the group) having edit authority.
This would also go along with being able to have
certain classes or types of articles to have some
level of "authority" assigned to them.

Most articles can be assigned a value of 0, meaning
anyone can edit them. Occasionally some articles
can be raised because of edit wars, without having
to use a binary lock/unlock on the article, where
there is a party who is known to be more reliable,
they can be allowed to do edits on the particular
disputed article, without they themselves having the
authority to decide to make the article blocked.
This would then allow a person with priveleges to
take the article out of an edit war, by simply
raising the user level needed to edit it, then users
who have shown to have more responsibility can be
allowed to make changes, without the user who raised
the access level having to get involved, thus
increasing the capacity for neutrality.

What the format of the privelege table is can be
whatever is appropriate depending upon what is
desirable to use in the database. It can be a table
of bytes, or anything you want to use, since it
attaches to the user's account, it's not a huge amount
of space as opposed to it being something that is
attached to every single article (except for a
minimum edit level requirement, or access bit table).

This would also allow consolidation of all of the
different priveleges and capabilities into one part
of the database instead of being a whole bunch of
different parts interspersed into lots of different
sections.

This also would allow persons re-implementing the
Wiki to provide different levels of access for
different users, and could allow some bits to be
used for tying some content to certain privelege
levels, for example, the Main Page cannot be edited
unless you have a higher level of privelege. I
guess this is a function of threats of vandalism,
and is an unfortunate change.

Had this restriction been in effect when I thought
up the idea of putting in a quick index in Wiktionary,
I would have been unable to do so. I note that once
I had the idea of including a quick index, it was
such a good idea that it has remained as a permanent
feature of the first page of Wiktionary. I was able
to implement this really useful feature immediately,
and make something available to everyone as a result.

Having the front page edit privelege be given to some
people, for example, someone who just needs that
capability doesn't need to have the capability to
block other users, and so on. It can be used to give
finer-grained control where it is needed.

Again, it's not necessarily for Wikimedia to use the
extra control, but potentially for other systems to
be able to use it. For example, a company could set
up a wiki about their products that allows people to
make changes, but the pages that are about the company
itself or that represent certain material that is
critical can be made non-editable by most users, but
some trusted users - who are not necessarily
employees - can be given priveleges to change those
classes of pages, or perform other functions, without
necessarily being able to change everything or do
other changes which for legal or technical reasons
they should not have the capacity to do.

Version: unspecified
Severity: enhancement