[Foundation-l] How bureaucracy works: the example

Milos Rancic millosh at gmail.com
Sat Sep 25 19:11:20 UTC 2010


On Sat, Sep 25, 2010 at 18:49, Marcus Buck <me at marcusbuck.org> wrote:
> Okay. Could you elaborate on that? What do you think should be changed?
> Which requirements are not well defined?
>
> So far I don't understand where exactly you see the influence of "bad
> bureaucracy" playing a role here.

Around a year ago:
* I have usability problem with Commons upload. (1)
* I complain about it.
* I am redirected to the Bugzilla.
* I am not willing to fill the bug *2.
* (I think that I mentioned that issue here a year or so ago.)

A couple of months ago:
* I have the same usability problem... complain to the different
person... answer is: MediaWiki is not finished as Wikipedia isn't.

Today:
* I have the same usability problem...

(1) Usability problem at Commons
* The first part of the problem is in software (JavaScript).
** The software problem is also link behavior. The similar type of
links on that page opens new web page and AJAX feature. (Sign + at the
bottom opens category browser.)
** The problem is existence of link to Permissions in software with
such problem, too. Without that link, user would be able just to click
on the question mark and to clearly see that link would be opened as a
regular web page.
** I am not the only person who uses Commons and I am sure that this
problem is well known among users.
* The second part of the problem are requirements for uploading image.
I was not allowed to post the image before I:
** wrote inside of the form that permission is {{pd}} -- although it
was not as {{Copyright by Wikimedia}} template was not recognized as a
valid template;
** then, after {{pd}} hasn't been recognized as a valid template
inside of the second form (the form which you get *sometimes* if you
didn't fill the form well and under unknown circumstances), I had to
write again {{Copyright by Wikimedia}} and it has been accepted.
* In the mean time, I spent the most of the time in testing what works
and what doesn't work.

(2) Filling the bug at Bugzilla.

* As a Wikimedia bureaucrat I am filling those bugs regularly,
whenever new language edition of some Wikimedia projects is needed.
Sometimes projects have been opened quickly, sometimes they haven't
been. Sometimes it is important to open the project quickly and I am
pushing that when it is needed. But, generally, I am fine with this
procedure, as this is not my part of the job. I did my best, it is
known what should be done and I have nothing to add there. Besides
that, this is a kind of regular task for WMF tech staff. [1]

* However, in the most of other cases I am filling bug requests as an
ordinary MediaWiki/Wikimedia user. And this is Kafkian, too: The best
chances are not to have solved problem at all. For example, bug 20061
[2] says that if you type [[chapter:nl:]] from Wikipedia in Serbian
(it is probably true for all other Wikimedia projects in Serbian), you
will go to http://sr.wikimedia.org/nl: -- which is nothing. This bug
hasn't been solved for more than year, although the solution should be
relatively simple database hack by changing the redirect keyword
"chapter" from http://sr.wikimedia.org/ to http://rs.wikimedia.org/.

But, let's say we don't care a lot about that and that we are able to
write the full URL for anything related to Wikimedia chapters at
Wikipedia in Serbian.

The second option is to spend a lot of time in explaining what is
needed and again not to get the result. The third option is to spend
much more time and to finally get the result.

After such experience I have to weigh the size of the problem as well
as how do I care about it personally. In the case of Commons bug I've
realized that it is easier to me to upload images just if I have to
and not to pass to the third option and spend a lot of energy in
arguing that it is important to resolve that bug.

Note that I am very well introduced in Wikimedia projects and that I
know what is the right address for filling a bug request. A random
Wikimedian who has similar problem probably doesn't know that
bugzilla.wikimedia.org exists at all. And, according to the present
situation, it seems that it is better.

Combined together, it is a very fertile material for writing a good
satire about our bureaucracy.

I am leading a small IT department in a company with 50+ employees. We
are treated as "the room for the rest", which is usual treatment of IT
departments in smaller companies. We are administrating servers and
workstations, we are programming, we are making Power Point
presentations when management really needs it and there is no one
around who knows it, we are dealing with electrical and phone
installations etc.; it is often the part of our job is to do
psychotherapy, too; although we are just admins, programmers and
designers.

So, I know how important is to say "no". Because of that I understand
why it should be a bit harder to upload a file at Commons and why it
should be a bit harder to push some needed bug request.

However, the combination of a couple of small mistakes from both sides
creates a very frustrating environment for work.

And to say again in reply to Jim: It is not a kind of bureaucracy in
the sense of high-level corruption; it is a kind of bureaucracy with
whom any ordinary person faces everyday. It is not evil by nature, it
is just not well managed.

And, again, the system is too complex to say that it is a
responsibility of a particular person. This is a kind of chained
problem: if one person waits for one day and there are 100 persons in
the chain, instead of solving issue in a couple of days, we'll have to
wait more than three months. With good chances that person 64 will
forget for the issue.

[1] BTW, the whole process also leads to the Kafkian bureaucracy from
the point of persons interested in project creation. There are three
time holes in the process of opening a new project: (1) speed of
recognizing new request; (2) speed of recognizing that everything need
has been done (localization + sustainable activity); and (3) project
creation after the final approval. But, at last, in this case it is
possible to recognize what the problems are and to fix them.

[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=20061



More information about the foundation-l mailing list