Mailing List Archive

Hoi,
Most of the developers are volunteers. There is certainly too much work in
the first place. It is a stellar performance what so few people do with so
little investment.

Their first priority is to keep the servers operational, combine this with
the growth that we experience this is a big job. There are several big jobs
that have been postponed time and again for many many months (think single
login or the inclusion of software that has been programmed and is waiting
for inclusion in the software).

When you find yourself a developer to program for you, it does not mean that
the software will be accepted; the only thing achieved is that you are
closer to getting it accepted. This is not to say that Bugzilla is busted,
it is that your expectations are not compatible with reality.

PS when you expect developers to reply to your wishes, you have to realise
that that too is work..

Thanks,
GerardM


On 9/23/06, Birgitte SB <birgitte_sb@yahoo.com> wrote:
>
> The subject line pretty much sums this note up. I am
> frustrated with the continued lack of development
> support for anything where the propents are not
> actually developers themselves. I have aware for
> sometime that asking for anything without uploading a
> "patch" is absolutely useless. So I accepted people
> that don't know what a patch is are just screwed. But
> I have recently realized many of developments which
> have never happened *did* have attachments (which I
> think are "patches"). The bugzilla system really must
> be broken. Because how can these things just be
> ignored for so long? Here is the bug which had the
> most effort invested in it from WS.
>
> http://bugzilla.wikimedia.org/show_bug.cgi?id=4375
>
> This feature was so desired by people Wikisource a
> show of support by 15 separte languages was
> orchestrated hoping it would have some effect.
>
>
> http://wikisource.org/wiki/Wikisource:Vote_on_enabling_the_ProtectSection_extension
>
> This was back in January. Nothing ever happened. The
> underlying problem this feature would solve will now
> hopefully be able to be addressed by "Stable version".
> At least I hope "stable versions" will be workable.
> But the last email about how de.WP wants a much more
> complicated system for this worries me.
>
> There are other technical issues that have projects on
> WS at a standstill.
>
> http://bugzilla.wikimedia.org/show_bug.cgi?id=189
>
> http://bugzilla.wikimedia.org/show_bug.cgi?id=5881
>
> I ask people online. Bugs are filed. Nothing
> happens. I do not want to make the effort to get all
> sub-domains to show support for these new features
> when it will have no effect. I realize that the
> developers are volunteers and are able to chose what
> interests them and where they would like to work. But
> they do not even give any feedback or even tell us
> they will not help us and we should learn to live
> without it. We just wait month upon month hoping it
> is on someone's to-do list somewhere. It is beyond
> frustrating. Has anyone else experienced these
> problems?
>
>
> Birgitte SB
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> foundation-l mailing list
> foundation-l@wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>
_______________________________________________
foundation-l mailing list
foundation-l@wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/foundation-l

How many months/years do you believe is a realistic
expectation?

Birgitte SB

--- GerardM <gerard.meijssen@gmail.com> wrote:

> Hoi,
> Most of the developers are volunteers. There is
> certainly too much work in
> the first place. It is a stellar performance what so
> few people do with so
> little investment.
>
> Their first priority is to keep the servers
> operational, combine this with
> the growth that we experience this is a big job.
> There are several big jobs
> that have been postponed time and again for many
> many months (think single
> login or the inclusion of software that has been
> programmed and is waiting
> for inclusion in the software).
>
> When you find yourself a developer to program for
> you, it does not mean that
> the software will be accepted; the only thing
> achieved is that you are
> closer to getting it accepted. This is not to say
> that Bugzilla is busted,
> it is that your expectations are not compatible with
> reality.
>
> PS when you expect developers to reply to your
> wishes, you have to realise
> that that too is work..
>
> Thanks,
> GerardM
>
>
> On 9/23/06, Birgitte SB <birgitte_sb@yahoo.com>
> wrote:
> >
> > The subject line pretty much sums this note up. I
> am
> > frustrated with the continued lack of development
> > support for anything where the propents are not
> > actually developers themselves. I have aware for
> > sometime that asking for anything without
> uploading a
> > "patch" is absolutely useless. So I accepted
> people
> > that don't know what a patch is are just screwed.
> But
> > I have recently realized many of developments
> which
> > have never happened *did* have attachments (which
> I
> > think are "patches"). The bugzilla system really
> must
> > be broken. Because how can these things just be
> > ignored for so long? Here is the bug which had
> the
> > most effort invested in it from WS.
> >
> > http://bugzilla.wikimedia.org/show_bug.cgi?id=4375
> >
> > This feature was so desired by people Wikisource a
> > show of support by 15 separte languages was
> > orchestrated hoping it would have some effect.
> >
> >
> >
>
http://wikisource.org/wiki/Wikisource:Vote_on_enabling_the_ProtectSection_extension
> >
> > This was back in January. Nothing ever happened.
> The
> > underlying problem this feature would solve will
> now
> > hopefully be able to be addressed by "Stable
> version".
> > At least I hope "stable versions" will be
> workable.
> > But the last email about how de.WP wants a much
> more
> > complicated system for this worries me.
> >
> > There are other technical issues that have
> projects on
> > WS at a standstill.
> >
> > http://bugzilla.wikimedia.org/show_bug.cgi?id=189
> >
> > http://bugzilla.wikimedia.org/show_bug.cgi?id=5881
> >
> > I ask people online. Bugs are filed. Nothing
> > happens. I do not want to make the effort to get
> all
> > sub-domains to show support for these new features
> > when it will have no effect. I realize that the
> > developers are volunteers and are able to chose
> what
> > interests them and where they would like to work.
> But
> > they do not even give any feedback or even tell us
> > they will not help us and we should learn to live
> > without it. We just wait month upon month hoping
> it
> > is on someone's to-do list somewhere. It is
> beyond
> > frustrating. Has anyone else experienced these
> > problems?
> >
> >
> > Birgitte SB
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam
> protection around
> > http://mail.yahoo.com
> > _______________________________________________
> > foundation-l mailing list
> > foundation-l@wikimedia.org
> >
>
http://mail.wikipedia.org/mailman/listinfo/foundation-l
> >
> _______________________________________________
> foundation-l mailing list
> foundation-l@wikimedia.org
>
http://mail.wikipedia.org/mailman/listinfo/foundation-l
>


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
foundation-l mailing list
foundation-l@wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/foundation-l

Yeah, the funny thing is that Wikimedia needs dev's a hell of a lot
more than it needs editors or even admins. Why are they so hard to
get? We're all geeks, right? Step up, people!

It was posted here recently that KDE (
http://mail.wikipedia.org/pipermail/foundation-l/2006-September/010129.html
) is interested in doing some training type thing with Wikiversity. I
think this is a brilliant idea. Mediawiki development was mentioned in
passing and it's a shame it probably won't happen. It doesn't really
help that the documentation is quite often all over the place, spread
over 2 wikis, sometimes without even mentioning which version is being
talked about. I found this a hassle just trying to administrate my own
wiki and frequent comments on meta show that many others do too. So to
really get into it, you have to really immerse yourself in it, which
is not really as easy as just checking your watchlist each day.

To Birgitte: I recommend befriending some developer or toolserver
types, and occasionally throw in a casual request for the status of
your latest (least) favourite bug. See if you can get someone to write
a toolserver tool that performs more or lless the same function as
MediaWiki should. This has been a remarkably successful approach at
Commons, although we'd prefer the MW solution of course. :)

Oh and voting means nothing, except for email update reminders.

That all said, I recognise the dev's face incredible demands on their
time from everyone and everything, including many 'invisible' factors
(well, invisible until they break!) and obviously worship the ground
they work on. (Please fix my bugs. Really. :))

cheers
Brianna
user:pfctdayelise


On 24/09/06, Birgitte SB <birgitte_sb@yahoo.com> wrote:
> How many months/years do you believe is a realistic
> expectation?
>
> Birgitte SB
>
> --- GerardM <gerard.meijssen@gmail.com> wrote:
>
> > Hoi,
> > Most of the developers are volunteers. There is
> > certainly too much work in
> > the first place. It is a stellar performance what so
> > few people do with so
> > little investment.
> >
> > Their first priority is to keep the servers
> > operational, combine this with
> > the growth that we experience this is a big job.
> > There are several big jobs
> > that have been postponed time and again for many
> > many months (think single
> > login or the inclusion of software that has been
> > programmed and is waiting
> > for inclusion in the software).
> >
> > When you find yourself a developer to program for
> > you, it does not mean that
> > the software will be accepted; the only thing
> > achieved is that you are
> > closer to getting it accepted. This is not to say
> > that Bugzilla is busted,
> > it is that your expectations are not compatible with
> > reality.
> >
> > PS when you expect developers to reply to your
> > wishes, you have to realise
> > that that too is work..
> >
> > Thanks,
> > GerardM
> >
> >
> > On 9/23/06, Birgitte SB <birgitte_sb@yahoo.com>
> > wrote:
> > >
> > > The subject line pretty much sums this note up. I
> > am
> > > frustrated with the continued lack of development
> > > support for anything where the propents are not
> > > actually developers themselves. I have aware for
> > > sometime that asking for anything without
> > uploading a
> > > "patch" is absolutely useless. So I accepted
> > people
> > > that don't know what a patch is are just screwed.
> > But
> > > I have recently realized many of developments
> > which
> > > have never happened *did* have attachments (which
> > I
> > > think are "patches"). The bugzilla system really
> > must
> > > be broken. Because how can these things just be
> > > ignored for so long? Here is the bug which had
> > the
> > > most effort invested in it from WS.
> > >
> > > http://bugzilla.wikimedia.org/show_bug.cgi?id=4375
> > >
> > > This feature was so desired by people Wikisource a
> > > show of support by 15 separte languages was
> > > orchestrated hoping it would have some effect.
> > >
> > >
> > >
> >
> http://wikisource.org/wiki/Wikisource:Vote_on_enabling_the_ProtectSection_extension
> > >
> > > This was back in January. Nothing ever happened.
> > The
> > > underlying problem this feature would solve will
> > now
> > > hopefully be able to be addressed by "Stable
> > version".
> > > At least I hope "stable versions" will be
> > workable.
> > > But the last email about how de.WP wants a much
> > more
> > > complicated system for this worries me.
> > >
> > > There are other technical issues that have
> > projects on
> > > WS at a standstill.
> > >
> > > http://bugzilla.wikimedia.org/show_bug.cgi?id=189
> > >
> > > http://bugzilla.wikimedia.org/show_bug.cgi?id=5881
> > >
> > > I ask people online. Bugs are filed. Nothing
> > > happens. I do not want to make the effort to get
> > all
> > > sub-domains to show support for these new features
> > > when it will have no effect. I realize that the
> > > developers are volunteers and are able to chose
> > what
> > > interests them and where they would like to work.
> > But
> > > they do not even give any feedback or even tell us
> > > they will not help us and we should learn to live
> > > without it. We just wait month upon month hoping
> > it
> > > is on someone's to-do list somewhere. It is
> > beyond
> > > frustrating. Has anyone else experienced these
> > > problems?
> > >
> > >
> > > Birgitte SB
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Tired of spam? Yahoo! Mail has the best spam
> > protection around
> > > http://mail.yahoo.com
> > > _______________________________________________
> > > foundation-l mailing list
> > > foundation-l@wikimedia.org
> > >
> >
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
> > >
> > _______________________________________________
> > foundation-l mailing list
> > foundation-l@wikimedia.org
> >
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> foundation-l mailing list
> foundation-l@wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>
_______________________________________________
foundation-l mailing list
foundation-l@wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/foundation-l

--- Brianna Laugher <brianna.laugher@gmail.com> wrote:

.
>
> To Birgitte: I recommend befriending some developer
> or toolserver
> types, and occasionally throw in a casual request
> for the status of
> your latest (least) favourite bug. See if you can
> get someone to write
> a toolserver tool that performs more or lless the
> same function as
> MediaWiki should. This has been a remarkably
> successful approach at
> Commons, although we'd prefer the MW solution of
> course. :)

Unfortunately I do not believe the toolserver can help
us display musical notation, protect only a portion of
a page from editing, or allow specialized
transclution. I do try to remind people about
outstanding issues but I am wondering how many other
people are becoming frustrated with this. It seems a
great deal of very minor issues are handled for en.WP
very quickly. They have recently gotten help to
rearrange the side bar display of all things. Yet
everyone says the developers are overworked. So I
would think somehow this system of prioritizing what
gets done (bugzilla) must be broken.

Now this is my personal opinion. I care ten times
more that the development needs of my community are
more fairly addressed, than that the community's
voices in the Board Elections are not drowned out by
en.WP.

Birgitte SB

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
foundation-l mailing list
foundation-l@wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/foundation-l

Birgitte SB wrote:
> The subject line pretty much sums this note up. I am
> frustrated with the continued lack of development
> support for anything where the propents are not
> actually developers themselves.

The purpose of the bug tracker is to do two things:

* Ensure that bug reports and feature requests are in a central, searchable
place where they will be seen and not be lost

* Ensure that there is at least some tracking of completion of issues.

As long as those are happening (and they are), then Bugzilla is *not* a failure.
If you don't believe me, look in MediaWiki's RELEASE-NOTES file and read the bug
numbers of the fixed/implemented issues per major release.

Please keep in mind what the bug tracking system replaces: a series of dozens of
wiki pages on a dozen separate wikis containing requests and complaints, which
weren't read by anyone and from which things would disappear never to be seen again.


Now, just because someone (or even several people) have requested something
doesn't mean it'll get done, any more than having several people write a letter
to a congressman or send a petition to a corporation will mean that the
government or company will do that thing.

In addition to someone, somewhere wanting it, it also has to fit with the
interests and priorities of the group that would actually effect it.

Some "neat features" may simply have no priority to the group that does the work
and runs the operations of the site. Manpower is limited, and effort goes, in
rough order, to:
1) Things that are really, really important to keep the site running
2) Things that someone writing code things are useful and/or neat

Some bugs are either very difficult to fix or have small enough effects that
someone has to decide to put in the effort to track it down and may not consider
it worth doing immediately.

> I have aware for
> sometime that asking for anything without uploading a
> "patch" is absolutely useless.

This is false, but I realize it's easy to feel that way if your own request is
not being fulfilled. Take a peak at the thousands of other requests, and you may
notice that there are other things to do.

> I have recently realized many of developments which
> have never happened *did* have attachments (which I
> think are "patches"). The bugzilla system really must
> be broken. Because how can these things just be
> ignored for so long?

1) Patches have to be looked at, understood, and accepted. As with pieces of
legislation "suggested" by a lobbyist group, legislators might want to take a
look at it before they vote on it.

Some patches are not good code. Some patches would damage the system or destroy
the performance of the entire site if they were simply installed.

Other times it's simply not known whether the feature *is actually desirable*.
Just because someone, somewhere wants it, even if the code *works*, it isn't
necessarily something that *should* be added.

Review may be a community or political issue as well as looking at actual code.


> Here is the bug which had the
> most effort invested in it from WS.
>
> http://bugzilla.wikimedia.org/show_bug.cgi?id=4375

This is "protected sections".

As I recall there is open debate about whether this is a desirable feature and,
if so, whether it should be implemented as in that code.

I don't recall anyone pushing for it in many months, though, so I assume there
is no longer any interest in it?

> There are other technical issues that have projects on
> WS at a standstill.
>
> http://bugzilla.wikimedia.org/show_bug.cgi?id=189

This is very low priority as there seems to be little active interest in it and
it requires a security review of third-party code which is reputed to be unsafe.
(If that's changed, we'd like to hear about it.)

> http://bugzilla.wikimedia.org/show_bug.cgi?id=5881

There is open debate about how this should work and what it should look like.
I've agreed in principal that we should be able to do something for this for
Wikisource but there is as far as I know no one currently attempting to reach
agreement on implementation.

Without this, having some disputed code doesn't actually mean anything will get
done.

If you're very interested, please keep bugging me about these things.

> I ask people online. Bugs are filed. Nothing
> happens. I do not want to make the effort to get all
> sub-domains to show support for these new features
> when it will have no effect. I realize that the
> developers are volunteers and are able to chose what
> interests them and where they would like to work.

Many developers are volunteers, but two of us are employed by the Foundation.
Primarily this means we have an extra commitment to site operations issues --
performance, security, etc -- but also it means we should pay more attention to
some of the Foundation's smaller sites.

Since there's a lot to do, it helps to make waves on specific issues to make
sure attention gets paid.

Foundation-L probably isn't the best place to do it, but whatever works. ;)

-- brion vibber (brion @ pobox.com)

On 9/23/06, Brion Vibber <brion@pobox.com> wrote:
> Foundation-L probably isn't the best place to do it, but whatever works. ;)

Perhaps Birgitte SB should subscribe to Mediawiki-L, where the
software is the focus of discussion?

As an aside, is there a publically joinable WMF operations related
list (technical site operations, networking and systems and code)?
These are areas I am interested in possibly contributing in...


--
-george william herbert
george.herbert@gmail.com
_______________________________________________
foundation-l mailing list
foundation-l@wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/foundation-l

On 23/09/06, Birgitte SB <birgitte_sb@yahoo.com> wrote:

> people are becoming frustrated with this. It seems a
> great deal of very minor issues are handled for en.WP
> very quickly. They have recently gotten help to
> rearrange the side bar display of all things. Yet
> everyone says the developers are overworked. So I
> would think somehow this system of prioritizing what
> gets done (bugzilla) must be broken.
> Now this is my personal opinion. I care ten times
> more that the development needs of my community are
> more fairly addressed, than that the community's
> voices in the Board Elections are not drowned out by
> en.WP.


It's an Americocentric conspiracy to take over Wikimedia, and
absolutely the most effective thing for you to do is Assume Bad Faith!
DOWN WITH EN:WP!!


No, actually it's probably because a lot of the devs start as editors
on en:wp and so that tends to be the project they hang around on and
hear the bugs of most. e.g. Rob Church, who has done a *remarkable*
amount of recent work on MediaWiki and can be found on en:wp and on
#wikipedia ... or Tim Starling, who started as a contributor, realised
there was an urgent need for development and sysadmin and pretty much
moved to that.

That is: if your project doesn't get its favourite bugs fixed, it's
not favouritism to en:wp - it's your project not contributing to the
development. These are volunteers, if you recall.


- d.
_______________________________________________
foundation-l mailing list
foundation-l@wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/foundation-l

--- Brion Vibber <brion@pobox.com> wrote:

> Birgitte SB wrote:

> > Here is the bug which had the
> > most effort invested in it from WS.
> >
> > http://bugzilla.wikimedia.org/show_bug.cgi?id=4375
>
>
> This is "protected sections".
>
> As I recall there is open debate about whether this
> is a desirable feature and,
> if so, whether it should be implemented as in that
> code.
>
> I don't recall anyone pushing for it in many months,
> though, so I assume there
> is no longer any interest in it?
>


I don't see any debate whether this desirable with
contributors from over 15 languages

http://wikisource.org/wiki/Wikisource:Vote_on_enabling_the_ProtectSection_extension

As to whether there is current interest, it depends on
whether "stable versions" will work for us or not. I
believe "stable versions' will do the trick but some
people want to see a woking model first. Besides this
possibility, no one has ever found an alternate
solution to "protect section". Without it we have
been forced to protect the entire page which is very
undesirable.

As to the rest, thanks for your explanation. I know
there is no easy answer to this. I did put this out
on foundation-l more to try and see if others are
having the same problems than to goad you. But I will
not complain if sometthing gets more attention due to
it ;)


Birgitte SB



__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
foundation-l mailing list
foundation-l@wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/foundation-l

George Herbert wrote:
> On 9/23/06, Brion Vibber <brion@pobox.com> wrote:
>> Foundation-L probably isn't the best place to do it, but whatever works. ;)
>
> Perhaps Birgitte SB should subscribe to Mediawiki-L, where the
> software is the focus of discussion?
>
> As an aside, is there a publically joinable WMF operations related
> list (technical site operations, networking and systems and code)?
> These are areas I am interested in possibly contributing in...

That would more or less be wikitech-l and the #wikimedia-tech channel on
irc.freenode.net. Operations and main code development are somewhat mixed.

We have an operations wiki as well, for documentation and logging rather than
discussion, which is open (but please don't abuse it):
https://wikitech.leuksman.com/

-- brion vibber (brion @ pobox.com)

--- David Gerard <dgerard@gmail.com> wrote:

> On 23/09/06, Birgitte SB <birgitte_sb@yahoo.com>
> wrote:
>
> > people are becoming frustrated with this. It
> seems a
> > great deal of very minor issues are handled for
> en.WP
> > very quickly. They have recently gotten help to
> > rearrange the side bar display of all things. Yet
> > everyone says the developers are overworked. So I
> > would think somehow this system of prioritizing
> what
> > gets done (bugzilla) must be broken.
> > Now this is my personal opinion. I care ten
> times
> > more that the development needs of my community
> are
> > more fairly addressed, than that the community's
> > voices in the Board Elections are not drowned out
> by
> > en.WP.
>
>
> It's an Americocentric conspiracy to take over
> Wikimedia, and
> absolutely the most effective thing for you to do is
> Assume Bad Faith!
> DOWN WITH EN:WP!!
>
>
> No, actually it's probably because a lot of the devs
> start as editors
> on en:wp and so that tends to be the project they
> hang around on and
> hear the bugs of most. e.g. Rob Church, who has done
> a *remarkable*
> amount of recent work on MediaWiki and can be found
> on en:wp and on
> #wikipedia ... or Tim Starling, who started as a
> contributor, realised
> there was an urgent need for development and
> sysadmin and pretty much
> moved to that.
>
> That is: if your project doesn't get its favourite
> bugs fixed, it's
> not favouritism to en:wp - it's your project not
> contributing to the
> development. These are volunteers, if you recall.
>
>
> - d.

Yes I do realize a big part of issue is that the
people interested in development are inherently not
interested in Wikisource. I was just trying to
compare this issue with everyone talking about en.WP
dominating election issues and voting (which everyone
seemed to classify as a "bad thing") But seriously to
everyone who thinks I am just being unrealistic here,
is nine months to short a time to start complaining?
Seriously what should my expectations be?


Birgitte SB

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
foundation-l mailing list
foundation-l@wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/foundation-l

On 9/23/06, Birgitte SB <birgitte_sb@yahoo.com> wrote:
>
>
> --- David Gerard <dgerard@gmail.com> wrote:
>
> > On 23/09/06, Birgitte SB <birgitte_sb@yahoo.com>
> > wrote:
> >
> > > people are becoming frustrated with this. It
> > seems a
> > > great deal of very minor issues are handled for
> > en.WP
> > > very quickly. They have recently gotten help to
> > > rearrange the side bar display of all things. Yet
> > > everyone says the developers are overworked. So I
> > > would think somehow this system of prioritizing
> > what
> > > gets done (bugzilla) must be broken.
> > > Now this is my personal opinion. I care ten
> > times
> > > more that the development needs of my community
> > are
> > > more fairly addressed, than that the community's
> > > voices in the Board Elections are not drowned out
> > by
> > > en.WP.
> >
> >
> > It's an Americocentric conspiracy to take over
> > Wikimedia, and
> > absolutely the most effective thing for you to do is
> > Assume Bad Faith!
> > DOWN WITH EN:WP!!
> >
> >
> > No, actually it's probably because a lot of the devs
> > start as editors
> > on en:wp and so that tends to be the project they
> > hang around on and
> > hear the bugs of most. e.g. Rob Church, who has done
> > a *remarkable*
> > amount of recent work on MediaWiki and can be found
> > on en:wp and on
> > #wikipedia ... or Tim Starling, who started as a
> > contributor, realised
> > there was an urgent need for development and
> > sysadmin and pretty much
> > moved to that.
> >
> > That is: if your project doesn't get its favourite
> > bugs fixed, it's
> > not favouritism to en:wp - it's your project not
> > contributing to the
> > development. These are volunteers, if you recall.
> >
> >
> > - d.
>
> Yes I do realize a big part of issue is that the
> people interested in development are inherently not
> interested in Wikisource. I was just trying to
> compare this issue with everyone talking about en.WP
> dominating election issues and voting (which everyone
> seemed to classify as a "bad thing") But seriously to
> everyone who thinks I am just being unrealistic here,
> is nine months to short a time to start complaining?
> Seriously what should my expectations be?
>
>
> Birgitte SB
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> foundation-l mailing list
> foundation-l@wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l

I think your expectations should be that:

A. Some methods of promoting enhancements to the code are more
effective than others, and that your series of emails here has
hopefully pointed you to some more effective methods.

B. As with many open source projects, there are probably many
enhancements that would be good, or at worst harmless, that do not
happen because nobody who actually does coding ends up highly
interested in the problem.

The ultimate solution to B is to successfully accomplish A. If you
don't seem to get leverage there, then you may want to learn PHP and
the MediaWiki codebase... A lot of enhancements ultimately happen
because one person wants it badly enough to code it, even if the
existing community didn't.

MediWiki is no different from any generic open source project in these regards.

The very best, very large development base projects can have a more
user-requirements-request driven approach, but that only works if you
have enough coders / developers that they have "spare time" beyond the
tasks they see as personal individual must-have or individual interest
drivers. I'm not sure how many people are working on MediaWiki right
now, but it seems relatively small for a very large userbase project.


--
-george william herbert
george.herbert@gmail.com
_______________________________________________
foundation-l mailing list
foundation-l@wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/foundation-l

Ultimately this is an issue of answering the following question: Does the
Wikimedia Foundation have a responsibility to help projects it hosts with
development resources?

It appears that to some degree, the answer is yes: the foundation pays for
hosting and proper maintenance of servers to ensure uptime, and pays for
some development to move the platform forward. However, so far the stance
has been that the projects are on their own when it comes to developing or
enabling additional features.

My recommendation would be that the foundation retains a technical assistant
(perhaps on a part-time basis); someone whose entire paid responsibility is
to be the arbiter of feature implementation. Sometimes this person's job
might be to enable an extension, and make sure it doesn't break things when
it goes live; other times it might be trying to help implement a particular
minor change. From trying to get some things deployed for Wikinews, I know
just how much of a pain it was to get a minor feature pushed through --
ultimately requiring months of back-and-forth for one page worth of code.
However, when we did get some of the technican Wikimedians' help (thank you
Brion!) we got our problems resolved within seconds.

I really believe that since Brion's job is likely to be defined in terms of
Wikimedia as a whole, it is cruicial to have someone else own the domain of
the little , individual problems on the technical front. This way the small
projects won't have to wait months for the smallest changes. I suspect that
having someone in that kind of a dedicated role will cut down a lot of
project frustration.

Alternatively, the foundation should make an explicit decision as to where
they want to deliniate the responsibility between the Foundation's technical
resources and the resources each project, chapter, or language is supposed
to provide to accomplish its goals. This way each project will know what
they need to do themselves and what they should be expecting from WMF-based
resources.

-ilya haykinson
en.wikinews

On 9/23/06, George Herbert <george.herbert@gmail.com> wrote:
>
> On 9/23/06, Birgitte SB <birgitte_sb@yahoo.com> wrote:
> >
> >
> > --- David Gerard <dgerard@gmail.com> wrote:
> >
> > > On 23/09/06, Birgitte SB <birgitte_sb@yahoo.com>
> > > wrote:
> > >
> > > > people are becoming frustrated with this. It
> > > seems a
> > > > great deal of very minor issues are handled for
> > > en.WP
> > > > very quickly. They have recently gotten help to
> > > > rearrange the side bar display of all things. Yet
> > > > everyone says the developers are overworked. So I
> > > > would think somehow this system of prioritizing
> > > what
> > > > gets done (bugzilla) must be broken.
> > > > Now this is my personal opinion. I care ten
> > > times
> > > > more that the development needs of my community
> > > are
> > > > more fairly addressed, than that the community's
> > > > voices in the Board Elections are not drowned out
> > > by
> > > > en.WP.
> > >
> > >
> > > It's an Americocentric conspiracy to take over
> > > Wikimedia, and
> > > absolutely the most effective thing for you to do is
> > > Assume Bad Faith!
> > > DOWN WITH EN:WP!!
> > >
> > >
> > > No, actually it's probably because a lot of the devs
> > > start as editors
> > > on en:wp and so that tends to be the project they
> > > hang around on and
> > > hear the bugs of most. e.g. Rob Church, who has done
> > > a *remarkable*
> > > amount of recent work on MediaWiki and can be found
> > > on en:wp and on
> > > #wikipedia ... or Tim Starling, who started as a
> > > contributor, realised
> > > there was an urgent need for development and
> > > sysadmin and pretty much
> > > moved to that.
> > >
> > > That is: if your project doesn't get its favourite
> > > bugs fixed, it's
> > > not favouritism to en:wp - it's your project not
> > > contributing to the
> > > development. These are volunteers, if you recall.
> > >
> > >
> > > - d.
> >
> > Yes I do realize a big part of issue is that the
> > people interested in development are inherently not
> > interested in Wikisource. I was just trying to
> > compare this issue with everyone talking about en.WP
> > dominating election issues and voting (which everyone
> > seemed to classify as a "bad thing") But seriously to
> > everyone who thinks I am just being unrealistic here,
> > is nine months to short a time to start complaining?
> > Seriously what should my expectations be?
> >
> >
> > Birgitte SB
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> > _______________________________________________
> > foundation-l mailing list
> > foundation-l@wikimedia.org
> > http://mail.wikipedia.org/mailman/listinfo/foundation-l
>
> I think your expectations should be that:
>
> A. Some methods of promoting enhancements to the code are more
> effective than others, and that your series of emails here has
> hopefully pointed you to some more effective methods.
>
> B. As with many open source projects, there are probably many
> enhancements that would be good, or at worst harmless, that do not
> happen because nobody who actually does coding ends up highly
> interested in the problem.
>
> The ultimate solution to B is to successfully accomplish A. If you
> don't seem to get leverage there, then you may want to learn PHP and
> the MediaWiki codebase... A lot of enhancements ultimately happen
> because one person wants it badly enough to code it, even if the
> existing community didn't.
>
> MediWiki is no different from any generic open source project in these
> regards.
>
> The very best, very large development base projects can have a more
> user-requirements-request driven approach, but that only works if you
> have enough coders / developers that they have "spare time" beyond the
> tasks they see as personal individual must-have or individual interest
> drivers. I'm not sure how many people are working on MediaWiki right
> now, but it seems relatively small for a very large userbase project.
>
>
> --
> -george william herbert
> george.herbert@gmail.com
> _______________________________________________
> foundation-l mailing list
> foundation-l@wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>
_______________________________________________
foundation-l mailing list
foundation-l@wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/foundation-l