[Foundation-l] Board Resolution: Openness

phoebe ayers phoebe.wiki at gmail.com
Sun Apr 10 19:54:40 UTC 2011


On Sat, Apr 9, 2011 at 9:36 PM, MZMcBride <z at mzmcbride.com> wrote:
> Risker wrote:
>> I'm particularly interested in policy simplification; I know our project has
>> far, far too many complex and even contradictory policies, guidelines, and
>> miscellaneous pages that result in "alphabet soup" messages that even
>> experienced users find almost impenetrable. I pity the newbie who gets a
>> "welcome" message that leads them to the Manual of Style, for example.
>> Featured article writers "discuss" what it really means on a regular basis,
>> so there's little hope an inexperienced editor will be able to follow the
>> contradictions in it.
>
> I agree that the collection of policies, guidelines, etc. has grown too
> large and too complex, but I'm not sure it's a particular problem (at least
> in the sense that you seem to be describing).
>
> I think most users don't pay any mind to the Manual of Style or the featured
> article requirements or anything like that. They might be inundated with too
> many links in welcome messages (which I view as a largely separate issue
> from policy creep), but I don't think the vast majority of editors pay any
> mind to the details of policies and pages that even established users can't
> be bothered to keep up with. This is what some argue is the actual meaning
> behind "ignore all rules." :-)

Here's my personal take on the complexity of policy/process, and why
it is good to try and simplify, clarify, condense, and otherwise make
it easier to use.

Some things are complicated by nature. Serial commas, citation
styles... I haven't met a style guide yet where such things weren't
spelled out in great and boring detail. Style guides should be easy to
find, easy to refer to, contain clear explanations and
non-contradictory advice, but... we also assume that not everyone will
follow them at every pass, which is just fine; people can still add
citations to articles and other people can fix them according to the
MoS.

But procedure that *impedes* normal, everyday editorial work because
it is so complex, so hard (because of the amount of time it requires
to implement, or because of difficult markup/templates, or difficulty
in finding consensus), so hard to interpret, or so unfriendly is a
problem. Think about these everyday questions and their
policy/procedure page answers:

* "how do I delete an article?" and its counterpart: "why was my
article deleted?"
* "how do I merge/split an article?"
* "hey, can I reference a blogpost in this article?"

There are formatting questions that aren't so easy to figure out either:
* "how do I put a footnote in an article?"
* "how do I find and insert an infobox?"

For any of these (and dozens of others) the official answer is pretty
much "Well, got an hour or three?"

We all know these are trouble spots; if you're like me just looking at
these questions raises the ghosts of a thousand mailing-list and
on-wiki discussions past. ("Nooo! Not blogs again!") But I think it's
useful to sometimes go back to an area of procedure that you don't use
or apply much yourself, and look at it with the eyes of a newbie. Does
it make sense? Sense in context? Is it doable? Is there a simple
version and a more complicated version, and do they contradict each
other? Etc. And then use the same principles to simplify, clarify, and
condense the areas of procedure that you do regularly use and know
well.

For instance, I rarely put articles up for deletion anymore or
otherwise participate in this process, since my editing time is
limited; occasionally I participate in an AfD, occasionally I feel the
need to prod something or rescue a speedy deletion. But every time I
do this these days, I find myself totally daunted and confused by
English Wikipedia deletion procedure -- and I wrote a book on the
subject. That's a pretty high bar to set!

-- phoebe

p.s. I am curious, too, if all languages have the same trouble spots
-- what are the most complicated, confusing, perhaps contentious areas
of process in your wikis? This would be a great cross-wiki embassy
topic.



More information about the foundation-l mailing list