(thread 1 in a 3-thread microseries)
The long-term discussion about planning for, devotion to, and passing on the message and goals of the projects falls to all of us -- not just the 700 people subscribed to this list, nor the 2000 contributors to Meta, nor just the 100,000 active editors across all the projects... but also those who care enough to donate money or critical rants or expert advice, readers who would not dare contribute to an encyclopedia but have relevant experiences in other areas of life to add to planning discussions, and the friends and colleagues and family of the above, interested enough to participate in such discussions if they knew about them but not yet aware they exist.[2]
Questions: what are the most important goals over the next few years a) for Wikipedia, b) for Wiktionary, Wikibooks, Commons and any further media repository, Wikisource, Wikinews, Wikiquote, Wikispecies, Wikiversity [I would forward to the other lists but for some of them it might double their annual list traffic] c) for Wikipedia and its sister projects in their secondary capacities of language preservation, debate facilitation, education, archiving d) for the Wikimedia Foundation, as a supportive entity and as an organization e) for each of us individually as community members
[forgive me for lumping together all of the smaller projects; and all languages, large, small, living, and dead]
Let us seed a longer discussion about planning for the future. To begin with, it would be helpful to gather together the many places where related discussions have already been held.
For instance, here is a new page on the subject: http://meta.wikimedia.org/wiki/Special_projects_committee/strategic_goals And an older page: http://meta.wikimedia.org/wiki/Three-year_plan And a series of essays: http://www.aaronsw.com/weblog/wikiroads
There are similar pages on individual projects and mailing lists, and in many languages other than English. Perhaps you have run across one before. I've started an Yet Another MetaMeta page on meta. Please contribute links to it and translate it:
http://meta.wikimedia.org/wiki/Planning_for_the_future
++SJ
[1] Perhaps a very long time. http://community.livejournal.com/wikipedians/17778.html
[2] For those who feel broad-based discussions are criminal, or wastes of time: the process of discussing plans for the future helps strengthen shared purpose and naturally passes on the message of the projects. And we don't have enough people talking about these ideas now; even excellent suggestions for investigation and research are allowed to lie fallow. We are very far from having too many voices offering their pearls of wisdom.
On 9/21/06, SJ 2.718281828@gmail.com wrote:
(thread 1 in a 3-thread microseries)
The long-term discussion about planning for, devotion to, and passing on the message and goals of the projects falls to all of us -- not just the 700 people subscribed to this list, nor the 2000 contributors to Meta, nor just the 100,000 active editors across all the projects...
There are only 23,611* active registered editors (as of June 1, 2006) on all projects.
Kelly
* "Active" is defined as "400 edits lifetime and 100 edits in the past year on any given project". This number is overstated because many people are "active" on more than one project, and until we get SUL I can't readily account for that.
Where is that definition from? I was using Erik Zachte's definition of "active member", as used in a half dozen presentations on Wikipedia -- ~80k editors with over 5 edits in the past month... 210k with over 10 edits in all. I think "100k active editors" is accurate, though perhaps "200k contributors" would be better.
http://stats.wikimedia.org/EN/TablesWikipediansEditsGt5.htm
SJ
On 9/21/06, Kelly Martin kelly.lynn.martin@gmail.com wrote:
On 9/21/06, SJ 2.718281828@gmail.com wrote:
(thread 1 in a 3-thread microseries)
The long-term discussion about planning for, devotion to, and passing on the message and goals of the projects falls to all of us -- not just the 700 people subscribed to this list, nor the 2000 contributors to Meta, nor just the 100,000 active editors across all the projects...
There are only 23,611* active registered editors (as of June 1, 2006) on all projects.
Kelly
- "Active" is defined as "400 edits lifetime and 100 edits in the past
year on any given project". This number is overstated because many people are "active" on more than one project, and until we get SUL I can't readily account for that. _______________________________________________ foundation-l mailing list foundation-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/foundation-l
On 9/21/06, SJ 2.718281828@gmail.com wrote:
Where is that definition from? I was using Erik Zachte's definition of "active member", as used in a half dozen presentations on Wikipedia -- ~80k editors with over 5 edits in the past month... 210k with over 10 edits in all. I think "100k active editors" is accurate, though perhaps "200k contributors" would be better.
It's one I came up with recently. Five edits in a month is not a good measure of "community". 400 edits lifetime and 100 edits a year shows more of a commitment to a project than five edits in a month, which could easily be a driveby editor who does not hang around. I'm considering running another stats run at 100 lifetime and 25 per year, since I think the higher number shortchanges the community size of smaller projects. (Almost half of our projects have no active editors by the 400/100 standard.)
Kelly
On 9/21/06, Kelly Martin kelly.lynn.martin@gmail.com wrote:
It's one I came up with recently. Five edits in a month is not a good measure of "community". 400 edits lifetime and 100 edits a year shows more of a commitment to a project than five edits in a month, which could easily be a driveby editor who does not hang around. I'm considering running another stats run at 100 lifetime and 25 per year, since I think the higher number shortchanges the community size of smaller projects. (Almost half of our projects have no active editors by the 400/100 standard.)
Interesting. It seems to me that community is proportional to attention and interest, not to edit count. Until we have measures of this, we are discounting the active readers and lurkers who edit only occasionally. On the other hand, we are overcounting people who edit on more than one project.
I look forward to single login, a decent user survey, and better metrics.
SJ
--- SJ 2.718281828@gmail.com wrote:
On 9/21/06, Kelly Martin kelly.lynn.martin@gmail.com wrote:
It's one I came up with recently. Five edits in a
month is not a good
measure of "community". 400 edits lifetime and
100 edits a year shows
more of a commitment to a project than five edits
in a month, which
could easily be a driveby editor who does not hang
around. I'm
considering running another stats run at 100
lifetime and 25 per year,
since I think the higher number shortchanges the
community size of
smaller projects. (Almost half of our projects
have no active editors
by the 400/100 standard.)
Interesting. It seems to me that community is proportional to attention and interest, not to edit count. Until we have measures of this, we are discounting the active readers and lurkers who edit only occasionally. On the other hand, we are overcounting people who edit on more than one project.
I look forward to single login, a decent user survey, and better metrics.
SJ ________
Active editor metrics should probably vary based on the maturity of the comunity. Many of the various communities have barely existed for an entire year.
Birgitte SB
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Am Freitag, 22. September 2006 03:39 schrieb SJ:
Questions: what are the most important goals over the next few years a) for Wikipedia, b) for Wiktionary, Wikibooks, Commons and any further media repository, Wikisource, Wikinews, Wikiquote, Wikispecies, Wikiversity [I would forward to the other lists but for some of them it might double their annual list traffic]
Wikimedia Commons goals are better software which we naturally don't want to demand solely from others but want to be able contributing to with less friction. Some of our goals: * Single login * CheckUsage directly in MediaWiki * CommonsTicker directly in MediaWiki (for example via a defined RSS feed that can be imported in any other Wikimedia or third party wiki: See as well "Instant Commons" idea) * Checked Versions for files in order to review not only negatively ("this file needs to be deleted") but also positively ("this file can be used safely and is useful") our content. * Wikidata in MediaWiki for uniform and queryable file descriptions. Every serious media repository in the world uses well defined description fields.
These are some high priority requirements for the visions of Wikimedia Commons coming true.
Have also a look at the thread on CommonsDelinker, our current pending solution to yet another software problem, wich adresses as well some expectations towards the Foundation (which thus has a little bit to do with the goals of the Foundation, although not the same ;-).
Cheers, Arnomane
Daniel Arnold wrote:
Wikimedia Commons goals are better software which we naturally don't want to demand solely from others but want to be able contributing to with less friction. Some of our goals:
- Single login
Real soon now. ;)
- CheckUsage directly in MediaWiki
- CommonsTicker directly in MediaWiki (for example via a defined RSS feed that
can be imported in any other Wikimedia or third party wiki: See as well "Instant Commons" idea)
- Checked Versions for files in order to review not only negatively ("this
file needs to be deleted") but also positively ("this file can be used safely and is useful") our content.
Would love to these too; bug me about them in October and keep bugging me until they happen!
- Wikidata in MediaWiki for uniform and queryable file descriptions. Every
serious media repository in the world uses well defined description fields.
That could be some ways off, but useful data that's not wikidata might be shorter term.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
Daniel Arnold wrote:
Wikimedia Commons goals are better software which we naturally don't want to demand solely from others but want to be able contributing to with less friction. Some of our goals:
- Single login
Real soon now. ;)
- CheckUsage directly in MediaWiki
- CommonsTicker directly in MediaWiki (for example via a defined RSS feed that
can be imported in any other Wikimedia or third party wiki: See as well "Instant Commons" idea)
- Checked Versions for files in order to review not only negatively ("this
file needs to be deleted") but also positively ("this file can be used safely and is useful") our content.
Would love to these too; bug me about them in October and keep bugging me until they happen!
Without commenting about specific requests, I never feel right about being a pain-in-the-ass about getting things done when I'm confident that the person doing the work is doing as much as he can with the resources available.
Single login would be nice, as would a more sophisticated search function, but since I have never even figured out how to use a simple bot.I really can't make any constructive contributions to those efforts.
Ec
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_ex...
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
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_ex...
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
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_ex...
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
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_ex...
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
--- 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
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.
--- 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
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.
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
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.
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.
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.)
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 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)
--- Brion Vibber brion@pobox.com wrote:
Birgitte SB wrote:
Here is the bug which had the most effort invested in it from WS.
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_ex...
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
wikimedia-l@lists.wikimedia.org