[Foundation-l] Development tasks and project needs (was: Positive discrimination related to smaller communities and projects)
GerardM
gerard.meijssen at gmail.com
Mon Mar 28 21:26:12 UTC 2005
In doing maintenance and development there is this 80/20% rule. There
are things that make a huge difference to people doing the work in the
projects that do not cost much in developer resources. The one thing
that is really important that some triage is done on the bugs editted
in Bugzilla to find these little gems. Development is not only about
the big developments but also about the little ones.
One issue that then arises is do you want a fix or do you want the all
singing all dancing gizmo. I was really happy when commons arrived, it
is still not 100% as we want it to be but it makes a world of
difference in the practice of our projects. The latest update on the
upload page was brilliant, it just needs this increase in length for
the filename field and it would make my life easier.
There are other features like this. The thing is we do not always the
perfect code straight away because we have to learn what perfection
should look like and, we want some features badly.
So lets make things better but spend money on the strategic stuff,
particularly when developers feel an itch things things will be fixed
and when things are not fixed because it is NOT wikipedia let us have
it fixed and spend money to get us the 80% of what we desperately
need..
Thanks,
GerardM
On 28 Mar 2005 22:27:00 +0100, Erik Moeller <erik_moeller at gmx.de> wrote:
> I am not aware of any serious discussions concerning a fork. DV suggested
> that video files might be best hosted on some external service, but I
> commented that Wikimedia has more than enough resources to do that, and
> that we mostly need to agree on which politically correct video codec to
> use. I strongly oppose both project and software forks for reasons that
> should be obvious.
>
> It is true that Wikinews is reaching the limits of human scaling. This is
> because we're getting so large that we will soon have to stop listing all
> stories on the Main Page, and will have to use separate index pages
> instead.
>
> When Wikinews started, I did set up such index pages for regions and
> topics. It already became clear during the demo phase that these are
> nearly impossible to maintain manually -- it's not a fun job, so it
> doesn't get done, especially because everyone with some small technical
> knowledge knows that a computer could do this.
>
> So, what's the solution?
>
> Since I'm the person Gerard spoke about who is going to implement
> structured data functionality over the next 3-4 months, my own resources
> are limited. However, I have offered in the past to act as a development
> task coordinator for the Wikimedia Foundation, and that offer still
> stands.
>
> Such a task coordinator would prioritize tasks, maintain contacts to
> potentially interested sponsors, and make recommendations on spending a
> certain part of our internal budget on development tasks. He would write
> the basic specifications, try to locate interested developers (both by
> inviting them directly, and by having public calls for tenders), watch
> over the implementation, and decide whether it meets the specs (together
> with the Board and the MediaWiki Release Manager, Brion Vibber).
>
> His Holiness JW III is not infinitely scalable. I believe I am well-
> qualified for the role in question, and it is something I would love to
> do. The WMF has hired Brion on a part-time basis. But that's not going to
> cut it. Brion has got his hands full making sure that all the crazy
> inventions by people like me actually work, fixing existing bugs, working
> on sponsor-specific tasks like OAI support for GuruNet, churning out
> releases, watching over scalability, and addressing high priority general
> project issues like single login.
>
> I strongly believe that a combined model of full-time employment for
> people like Brion, and task-based contracts for project-specific needs, is
> the only way forward.
>
> As for the specific needs Wikinews has, Ilya has already written a bit
> about that. I have a fairly good idea in my head how news feeds could work
> within MediaWiki in a scalable fashion. The question is, are we willing to
> spend the money to get this done?
>
> And Wikinews is not the only project which needs changes. Wikipedia,
> Wikisource, Wiktionary, Wikibooks, Wikispecies, Wikiquote, and very
> importantly, Wikicommons, would all benefit greatly from certain added
> functionality. Whenever I go to a meetup, I hear from a dozen people about
> all the new features which we need to make their projects, or projects
> within a project, work. Often these ideas are really bad. That's why there
> needs to be a gatekeeper process by which good ones are selected for
> implementation.
>
> Just because Wikipedia sort of works (even though we still don't have peer
> review functionality after more than 4 years), we shouldn't start
> slacking. We have half a dozen active developers at any given time. We
> have hundreds of thousands of users and even more readers. We've tried
> recruiting. Jimbo has given his speech at FOSDEM. There's more we can do,
> but in part due to the growing complexity of MediaWiki, this imbalance can
> ultimately only be addressed with one resource: money.
>
> Regards,
>
> Erik
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>
More information about the wikimedia-l
mailing list