[Foundation-l] Why is the software out of reach of the community?

Brian Brian.Mingus at colorado.edu
Sun Jan 11 03:20:48 UTC 2009

Thank for your answers.

ParserFunctions are my specific example of how the current development
process is very, very broken, and out of touch with the community.
According to Jimbo's user page (his bolded): "*Any changes to the software
must be gradual and reversible.* We need to make sure that any changes
contribute positively to the community, as ultimately determined by
everybody in Wikipedia, in full consultation with the community consensus."

I believe that the introduction of ParserFunctions to MediaWiki was not done
with community consensus and has led to an extremely  fast devolution in
wiki syntax. Further, the usability of Wikipedia has declined at a rate
proportional to the adoption of parser functions.

Is there *anybody* on this list that is willing to say that this is more
usable than what we had before?

I am quite sure that the answer to Wikipedia's usability issues was not
properly taken into concern when ParserFunctions were written. This is based
on a very simple principle that I am following in this discussion:
Improvements in usability in MediaWiki will not happen through the addition
of syntax, but rather the removal of syntax, and the improvement of the User
Interface Design.

I also believe this new grant will help, but I do not believe it will fix a
broken process. I would like to discuss that process further, and how it
could be improved.

On Sat, Jan 10, 2009 at 7:53 PM, Aryeh Gregor
<Simetrical+wikilist at gmail.com<Simetrical%2Bwikilist at gmail.com>
> wrote:

> On Sat, Jan 10, 2009 at 9:04 PM, Brian <Brian.Mingus at colorado.edu> wrote:
> > False: Extension Matrix.
> See the rest of that paragraph.  Anyone who can write code and wants
> commit access can get it.  The only ones without commit access who
> want it are those who can't or won't write code.  Most of the
> extension developers are apparently uninterested in getting commit
> access, since they haven't asked for it.  There is only a small
> barrier between developers, and people who are willing and able to
> code and want to become developers.
> > The development of MediaWiki should not be based on
> > what the core developers believe the flavor of the day is. It leads to
> > monstrosities such as the current parser.
> I already pointed out that the current parser was not originally
> written in the current development model.  It's not a reasonable
> example to support your point.
> > If the community funds MediaWiki
> > development, they should have a very strong say in what features get
> > implemented.
> The Wikimedia Foundation funds MediaWiki development.  It employs both
> of the core developers and therefore has total control over what
> features get implemented.  The Board delegates most of these decisions
> to its CTO, who's one of the core developers in question.
> > The developers should not be the ones deciding what their time should be
> > spent on.
> The majority of developers are volunteers, so no one else can decide
> what their time is spent on.  The few who are employees are told what
> to do by the Wikimedia Foundation, through its CTO Brion Vibber, as in
> any organization.  You appear to disagree with some of Brion's
> decisions, but he was appointed CTO and lead developer by the Board of
> Trustees.  How can he not have discretion to do what he thinks is
> best?  Who should, then?
> > And I am under the
> > impression that various language Wikipedia's can enable SMW if they reach
> a
> > consensus. Is that wrong?
> Yes.  All code must pass review regardless of consensus, and SMW has not.
> > And yet major features to MW have been implemented on developer whim.
> Not remotely as large as SMW, without the approval of a senior
> developer.  If you think you can find a counterexample, show me.
> > I'm curious: of all the possible
> > "improvements" to MediaWiki, why do you feel the horrifying "parser"
> > functions were chosen? For the increase in usability? Pfffft.
> ParserFunctions were developed to address the fact that the community
> was using horrible hacks like {{qif}} to achieve the functionality
> anyway.  The conclusion was that a relatively efficient and clean way
> of achieving basic logic was preferable to what people were devising.
> It's been proposed that we ditch these as well and move to embedding a
> real programming language instead, but there hasn't been much activity
> on that.
> > I do not believe the job of the core developers should be choosing what
> > extensions are enabled. If an extension appears to solve the usability
> > issue, and yet it does not scale, their job is to scale it.
> Someone must make the decision of what to spend limited development
> resources on.  In practice, that has to be a developer of some kind,
> because no one else would be informed enough to properly evaluate
> proposals on their merits.  The community can decide whether it wants
> a given extension, but it is in no position to determine whether the
> cost of fixing it up and enabling it is worth the benefit.  That must
> be made by some individual or group appointed for this purpose.  That
> would currently be the senior developers.
> > And when expert
> > PHP developers write extensions, give talks at Wikimania, provide
> community
> > support, and do what it takes to develop a thorough understanding of
> > MediaWiki, they should be given a larger voice. Much larger than being
> > ignored altogether.
> Any such person can ask for commit access and be given it.  If they
> gain the trust of the senior developers, they can potentially become
> trusted enough to do things like extension review themselves.  We've
> had people other than Tim and Brion who were allowed to enable
> extensions -- Avar, for instance (although that was a long time ago,
> when things were different).  In practice, nobody I know of meets your
> description.
> > I do not dispute review. I dispute the fact that the core developers only
> > review code that suits their fancy.
> They only review code that they have time to review.  There are two of
> them, what do you expect?  And not only must they review all code,
> they need to write code too, and fulfill other duties.
> I think the fundamental point you're missing here is lack of
> resources.  Brion and Tim do not fail to review Semantic MediaWiki
> because that's their "whim".  They simply don't have the resources to
> review everything.  They need to make decisions.  If they spent time
> reviewing SMW, that would be time they couldn't spend on other things.
>  They've judged that the other things are currently more important.
> On what basis do you question that judgment, since you evidently don't
> know what development resources *are* actually being spent on?
> > This is partly false. There have been several efforts to write a proper
> > parser, and the current parser has undergone major structural changes. I
> > don't believe a computer scientist would have a huge problem writing a
> > proper parser. Are any of the core developers computer scientists?
> If you're familiar with the attempts to write a parser, you're also
> familiar with the fact that they've all failed, because wikitext is
> unparseable using a real parser.  Tim knows a considerable amount of
> computer science, as well as understanding the requirements for a
> parser much better than any outsider, and would be the logical one to
> write a new parser -- but he's needed for a lot of other things as
> well.  Again, limited resources.
> > I do not believe that is how Firefox is developed.
> According to a statistic I recently saw, 80% of Firefox source code is
> written by people not employed by Mozilla.  Moreover, even the people
> employed by Mozilla live in radically different places.  Of the
> layout/content superreviewers, for instance, Google indicates that
> Robert O'Callahan lives in New Zealand, David Baron lives in
> California, Boris Zbarsky lives in Illinois, Jonas Sicking lives in
> Sweden, etc.
> So no, that's exactly how Firefox is developed.  Along with every
> other project that uses an open-source development model.  Open
> development inherently means you're willing to accept any
> contributors.  That means you accept them from anywhere in the world.
> That means over the Internet.
> > The linux kernel is
> > another story - it has proper oversight, and Torvald's "network of trust"
> -
> > 15 crack developers whom he knows well and have written exceptional
> quality
> > code for him for many years.
> What bearing does that have on what I said?  It's still perfectly good
> software developed over the Internet exclusively.
> On Sat, Jan 10, 2009 at 9:08 PM, Brian <Brian.Mingus at colorado.edu> wrote:
> > I was not disputing that the community should vote: In fact, I believe
> all
> > code that is written should be a result of a) community vote and b)
> rational
> > oversight provided by the foundation, but at a higher level than the core
> > developers.
> What's a "higher level than the core developers"?  Do you mean to
> imply that development resources should be allocated on a fine-grained
> level by non-developers?  How could anyone who's not a developer of
> the software make such decisions intelligently?  What, moreover, is
> wrong with the current system, other than the fact that it doesn't
> agree with you?
> On Sat, Jan 10, 2009 at 9:33 PM, Brian <Brian.Mingus at colorado.edu> wrote:
> > I do have another question: Who approved deploying parser functions on
> > Wikipedia?
> Tim Starling both wrote and deployed ParserFunctions.
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

You have successfully failed!

More information about the foundation-l mailing list