Chris Seaton wrote:
I don't want to nag, but I mailed a patch
(modification to the colonge
blue stylesheet) to this list a while ago and it hasn't been comitted to
CVS. Was I right to send it to this list or should it have gone
elsewhere? Do I have to do something special to get it comitted?
There are two methods of getting things done around here:
a) nagging
b) doing it yourself
(b) is usually easier than (a), so I suggest you do some of (a) to Brion
and get yourself CVS write access.
Long, long ago, Chris Seaton wrote:
Hello,
I have some extra time on my hands so I'm looking to do some development
on Wikipedia, as people always seem to be complaining about a lack of
developers.
I'm just getting the hang of things, browsing the source. I'm a good PHP
developer, but databases aren't my strong point (I can use them, but
can't really administer them).
I didn't know how to do either 6 months ago. I guess it depends on how
much time you've got to spend.
This is just a little patch to modify the fonts of the
stats section of
the colonge skin. This section is currently in serif, but the rest of
the page is in a sans font, so it looks out of
I was just planning to go through bugs and feature requests looking for
things that I can manage, is there something more pressing that you
would like to direct me to?
The sourceforge tracker is okay, but IMHO the best place to start is:
http://meta.wikipedia.org/wiki/Development_tasks
If you don't want to get into the DB side at this stage, perhaps you
should look at the UI. For example, at the moment users cannot access
the wikitext source of a protected page, and they can't get it if
they're blocked either. This is a GFDL violation.
The "code quality" section of the above page might also be up your
alley. If you're the violent type, there's plenty to be done maiming and
killing global variables.
Also, how frequently is the English wikipedia updated
to use the CVS
code?
See
http://meta.wikipedia.org/wiki/Development_policy. In theory
unstable->stable takes 3-10 days, then stable->live is "regularly". In
practice the unstable->stable step requires testing and debugging, and
until that's done, features just sit in unstable.
If you add a feature, you should always include the ability to switch it
on and off, using a global defined in DefaultSettings.php. This smooths
over the unstable->stable transition, and lessens "political" problems
involving controversial features.
-- Tim Starling.