[WikiEN-l] How wikipedia could link into File Protection.

Jay Litwyn brewhaha at freenet.edmonton.ab.ca
Wed Jul 29 12:04:01 UTC 2009 

It is an old idea that ran on IBM 370s in 1990. On them, what I am 
describing is child's play. On them I could also give you permission to read 
a file, and only with a certain program. "run only" for example was so 
common that it had an abreviation: "permit bugs run unsp:disasm" (permit 
user:bugs to run disasm as written in the filespace of user:unsp)-- and 
different permission for any user who asked. That means I can't debug it, I 
can't read it, and I certainly can't write it. Michigan Terminal System was 
so cheap with file space in those days, that I could not even expand it --  
writing a file and expanding it were different things. Today, a gigabyte is 
quite a bit less than a dollar. Back then, you could not get drives that 
big. Even though the system had a few terabytes of disk space, it was 
composed of *many* drives. Old idea. What wikipedia would need for using it 
is already a part of the file system that it runs on. I am trying to give it 
new wings.

My impression of file ownership on wikipedia is that the more effort you put 
into it, and how long, is the main predictor of much you do not feel like 
giving up on it -- no matter what the policy on ownership...well, inevitably 
there are articles out there superior to wikipedia because an author did 
take a point of view, and it happens to be more correct than anything you 
could find in the middle. Hey. You know what. I do not think policy changed 
when the permission controls were added, so that file in someone else's 
space for which everyone had unlimited access could've been bait.
_______
Does a Cheshire cat drink evaporated milk?

"FT2" <ft2.wiki at gmail.com> wrote in message 
news:e71d9fab0907221039vacb4be9g410afec43ab6c144 at mail.gmail.com...
> Maybe. But innovation is no bad thing, and if a disproportionate number of
> ideas are rejected too early rather than explored or trialled, perhaps 
> some
> that would find value will be lost.
>
> It's easy to forget that a wide range of processes and tools we take for
> granted today started off being considered questionable at their proposal.
>
> FT2
>
>
>
> On Wed, Jul 22, 2009 at 5:15 PM, Carcharoth 
> <carcharothwp at googlemail.com>wrote:
>
>> Maybe the ideas aren't good enough? :-)
>>
>> Carcharoth
>>
>> On Wed, Jul 22, 2009 at 5:04 PM, FT2<ft2.wiki at gmail.com> wrote:
>> > I have had an idea how we could help resolve POV and sourcing wars, 
>> > that
>> > would fit very well with Wikipedia philosophy. I might dust it off some
>> > time. The mood in the community is such that few proposals are welcomed
>> by
>> > sufficient users to get accepted, and at the same time the problems
>> persist
>> > and are critiqued.
>> >
>> > Anyone else notice that?
>> >
>> >
>> > FT2
>> >
>> >
>> > On Wed, Jul 22, 2009 at 3:00 PM, Jonathan Hall 
>> > <sinewave at silentflame.com
>> >wrote:
>> >
>> >> OK - so I think a fair summary of this proposal (correct me if I'm
>> wrong)
>> >> is:
>> >> We should create a group of experienced BLP editors (or similar) to
>> >> edit a BLP that has been the subject of an edit war. The page would be
>> >> protected from editing by other (non-sysop) users. This would form an
>> >> alternative to or replacement for page protection, and would hopefully
>> >> lead to more editing than page protection.
>> >> We should also allow users to create draft articles in their userspace
>> >> that are (by default) protected from editing by other non-sysops.
>> >>
>> >> I share FT2's concerns about the need to avoid creating a BLP cabal
>> >> with the first point, and I also have concerns about the second point
>> >> - it could lead to POV forks and encourage people to hide an imperfect
>> >> article in their userspace rather than it being more visible and
>> >> publically editable, which will lead to faster improvement. It could
>> >> also lead to greater feelings of article ownership - if you grew an
>> >> article to (say) A-class in your userspace before moving it to article
>> >> space you'll probably have greater feelings of ownership than if it
>> >> was in publically editablearticlespace from the start.
>> >>
>> >> On Tue, Jul 21, 2009 at 04:05, Jay
>> >> Litwyn<brewhaha at freenet.edmonton.ab.ca> wrote:
>> >> > Subject-Was: Re: A new solution for the BLP dilemma
>> >> >
>> >> > "Nothing new is under the sun", are among the most humbling of a
>> >> preacher's words. If you hav ever right-clicked on a file that you
>> uploaded
>> >> to your website (and you probably hav one that you are not using), 
>> >> then
>> >> clicked on "properties", you would be greeted with this menu of flags,
>> all
>> >> within your control:
>> >> >          R  W  P
>> >> >          e  r  e
>> >> >          a  i  r
>> >> >          d  t  m
>> >> >             e  i
>> >> >                t
>> >> > Owner:    X  X  O
>> >> > Group:    O  O  O
>> >> > Everyone: X  O  O
>> >> >
>> >> > Those would be appropriate settings for your user page, which is the
>> only
>> >> one that the system would let you own. Admins would be owners of all
>> pages
>> >> in main: and user: on wikipedia. That way, if you you refused to 
>> >> comply
>> with
>> >> one rule or another concerning how user space is used, then an admin
>> would
>> >> permit everyone to also be able to write to your space, so that a
>> volunteer
>> >> could show you his ignorance of those rules :-) I can almost see the
>> author
>> >> of "vandalproof" hanging his head and asking why he did not think of
>> that.
>> >> >
>> >> > group permission is a special feature of protected file systems.
>> Windows
>> >> does not hav group permission in XP, TMK, and it does let you protect
>> shared
>> >> objects from being written to. My web server is NetBSD, so it does hav
>> >> groups. Users can be added to groups, so that people who hav made
>> >> applications for being included in a group -- applications to a sysop
>> would
>> >> let you write files in a particular project, because you were a member
>> of
>> >> the required group.
>> >> >
>> >> > In a series of occurances, here is how a biography might become
>> >> authorized and get a special stamp of approval from the subject of the
>> >> biography.
>> >> > Someone write's a biography about someone else on their user page.
>> >> > They let it out among their collaborators.
>> >> > Two of those collaborators want to fix it, so the starter permits
>> >> everyone to write to it.
>> >> > An edit war breaks out, so the sysop (sysops always hav power to
>> permit,
>> >> as well as power to destroy, which is not displayed) retracts all
>> >> permission, except permission to a group, then assigns three veterans 
>> >> to
>> >> that group and solicits their attention to an article in progress.
>> >> > No blocks are issued.
>> >> > No significant flaws are in the wording or the evidence.
>> >> > The page is permitted for reading by all and writing by none.
>> >> > Occasionally, on the talk page, someone raises {{editprotected}}.
>> >> > The questions typically get an answer that could hav been found by
>> >> reading three months of history.
>> >> > _______________________________________________
>> >> > WikiEN-l mailing list
>> >> > WikiEN-l at lists.wikimedia.org
>> >> > To unsubscribe from this mailing list, visit:
>> >> > https://lists.wikimedia.org/mailman/listinfo/wikien-l
>> >> >
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> 1001010 1001000110000111011001101100
>> >>
>> >> _______________________________________________
>> >> WikiEN-l mailing list
>> >> WikiEN-l at lists.wikimedia.org
>> >> To unsubscribe from this mailing list, visit:
>> >> https://lists.wikimedia.org/mailman/listinfo/wikien-l
>> >>
>> > _______________________________________________
>> > WikiEN-l mailing list
>> > WikiEN-l at lists.wikimedia.org
>> > To unsubscribe from this mailing list, visit:
>> > https://lists.wikimedia.org/mailman/listinfo/wikien-l
>> >
>>
>> _______________________________________________
>> WikiEN-l mailing list
>> WikiEN-l at lists.wikimedia.org
>> To unsubscribe from this mailing list, visit:
>> https://lists.wikimedia.org/mailman/listinfo/wikien-l
>>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> https://lists.wikimedia.org/mailman/listinfo/wikien-l
>

More information about the WikiEN-l mailing list