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(a)gmail.com> wrote: -- ++SJ

On 9/21/06, Kelly Martin <kelly.lynn.martin(a)gmail.com> wrote: 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

Brion Vibber wrote: 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

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(a)yahoo.com> wrote:

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(a)yahoo.com> wrote:

On 23/09/06, Birgitte SB <birgitte_sb(a)yahoo.com> wrote: 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.

On 9/23/06, Birgitte SB <birgitte_sb(a)yahoo.com> wrote: 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(a)gmail.com

Birgitte SB wrote: 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. 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. 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. 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? 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. 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)

George Herbert wrote: 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)