On Thu, Sep 2, 2010 at 4:42 PM, Marcus Buck <wiki(a)marcusbuck.org> wrote:
My idea for that, as I said, is having a pool of
possible improvements
and then letting decide a mix of user ratings ("pro - we need this!",
"contra - not really necessary...") and common sense of the developers.
Create a page at Meta where people can propose things. Then check the
proposal (can it be implemented in a performant way? is it actually a
direction we want to develop to? technical traps? etc.pp.). If the check
is positive put the proposal on a second, protected, page on Meta and
let users vote pro and contra. Developers can then choose from the list
which project they want to implement next (preferring projects with high
ratings, but with room for an amount of common sense by the developers
because they know better about the technical feasibility).
We have this system already, it's called Bugzilla.
My main point is, that at the moment I as a user have
no chance to
influence the development of Wikimedia (except for doing it myself).
It's not possible to give users significant direct influence. There
are too many users and too few developers. Users are collectively
given significant say in development, but the influence is spread very
thin because the users are so numerous. You have little say because
there are many thousands of users whose say is weighted equally to
yours.
I
can pray or I can vote on Bugzilla but I have no way to predict when and
who takes the time to start a project. It would be nice to know that
there are people committed.
You do know when there are people committed, because the bug is
changed to ASSIGNED (or FIXED if it's quick). Usually there are no
people committed, but this is because there are vastly more ideas than
implementer time, not because of procedural issues.
If I have an idea, what do I do at the moment? I can
post on wikitech-l.
I will be told that the best way to get it done is by doing it myself. I
can go to Meta and propose something there. On Meta nobody will even
read it. So what I would like to have is a process. When I make a
proposal it should either get rejected or it should end up in the
above-mentioned pool and be implemented sooner or later dependant on its
importance.
This is exactly what Bugzilla does. In practice, of course, the
overwhelming majority of feature requests there are not fixed, but
again, this is not a problem with the process and it cannot be fixed
or even mitigated by changing the process.