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

[Fred Bauder]

Yes, ParserFunctions has been a nightmare for me, a detour into coding
that, while challenging, defeats the essence of a wiki, quick.

Fred

> 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?
> http://en.wikipedia.org/w/index.php?title=Template:Infobox&action=raw
>
> 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!
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>