Is there anyone out there who has considered contributing to the MediaWiki PHP script, but decided it against for reasons such as:
* Don't know PHP/MySQL * Poor documentation, can't understand the code * Wouldn't know where to start * Don't have a test server * Don't have CVS/server access, and you find contributing otherwise to be tedious and frustrating
Or perhaps you've contributed on occasion but you're deterred from contributing again for reasons such as those above?
If so, please speak up! What areas could we improve to make it easier to contribute?
If you prefer, you can contact me privately at tstarlingphysicsunimelbeduau.
-- Tim Starling.
On Fri, 2003-10-31 at 00:29, Tim Starling wrote:
Is there anyone out there who has considered contributing to the MediaWiki PHP script, but decided it against for reasons such as:
- Don't know PHP/MySQL
- Poor documentation, can't understand the code
- Wouldn't know where to start
- Don't have a test server
- Don't have CVS/server access, and you find contributing otherwise to
be tedious and frustrating
Or perhaps you've contributed on occasion but you're deterred from contributing again for reasons such as those above?
I know PHP, MySQL, CVS, HTML et cetera all to a reasonable standard, and thought you would all be gagging for me.
I tried to start developing, but found myself largely ignored. I asked for suggestions as to where to start, what were the areas that needed work, but was just vaguely pointed towards the bug reports.
If someone had said you can do X - something attainable within a few hours - I would have probably been hooked.
I made one commit to CVS, but it still hasn't gone onto the English Wikipedia (it was only one line).
That's why I gave up trying. Anyway, that was the summer holidays. Now I at Uni with much less free time.
My pointers: - Be very enthusiastic when someone comes forward - Give them something to get hooked on - Access to a test server
If so, please speak up! What areas could we improve to make it easier to contribute?
If you prefer, you can contact me privately at tstarlingphysicsunimelbeduau.
-- Tim Starling.
Wikitech-l mailing list Wikitech-l@Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On Thursday, Oct 30, 2003, at 16:36 US/Pacific, Chris Seaton wrote:
I tried to start developing, but found myself largely ignored. I asked for suggestions as to where to start, what were the areas that needed work, but was just vaguely pointed towards the bug reports.
If someone had said you can do X - something attainable within a few hours - I would have probably been hooked.
What we need are bug fixes and performance improvements. Unfortunately this isn't very sexy; you need to have some familiarity with the code to understand how it works and track down the bits that don't work right or don't run well, and that's work:
http://meta.wikipedia.org/wiki/Development_tasks
Instead, newcomers tend to want to add sexy new features that scratch their personal itches. These can be neat, but they also introduce new bugs and new slowdowns. We don't need new features right now. We need ugly, unpleasant grunt work that no one wants to do.
I made one commit to CVS, but it still hasn't gone onto the English Wikipedia (it was only one line).
We're *all* overworked. If something isn't getting done, you have to either do it yourself or speak up. In this case, speak up.
My pointers:
- Be very enthusiastic when someone comes forward
- Give them something to get hooked on
- Access to a test server
A public test server that won't wipe out our live server if something goes wrong would be great. Who wants to set that up? Lee at least did provide access to his server for this purpose, I don't know if that's still going on.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
On Thursday, Oct 30, 2003, at 16:36 US/Pacific, Chris Seaton wrote:
I tried to start developing, but found myself largely ignored. I asked for suggestions as to where to start, what were the areas that needed work, but was just vaguely pointed towards the bug reports.
If someone had said you can do X - something attainable within a few hours - I would have probably been hooked.
What we need are bug fixes and performance improvements. Unfortunately this isn't very sexy; you need to have some familiarity with the code to understand how it works and track down the bits that don't work right or don't run well, and that's work:
http://meta.wikipedia.org/wiki/Development_tasks
Instead, newcomers tend to want to add sexy new features that scratch their personal itches. These can be neat, but they also introduce new bugs and new slowdowns. We don't need new features right now. We need ugly, unpleasant grunt work that no one wants to do.
There are a fair few sorely needed features which won't slow down there server. For example, a warning when people overwrite images, or the ability to access the source of protected pages. However, I'm certainly not doing new features at the moment -- it's been far too long since the branches were last merged, so I'm working on cleaning up the unstable branch, not optimisation.
New features do indeed introduce new bugs, but I'd be willing to tolerate a few new bugs in exchange for a new developer.
I made one commit to CVS, but it still hasn't gone onto the English Wikipedia (it was only one line).
We're *all* overworked. If something isn't getting done, you have to either do it yourself or speak up. In this case, speak up.
My pointers:
- Be very enthusiastic when someone comes forward
- Give them something to get hooked on
- Access to a test server
A public test server that won't wipe out our live server if something goes wrong would be great. Who wants to set that up? Lee at least did provide access to his server for this purpose, I don't know if that's still going on.
Lee's server is still around, although it's a bit broken. The database schema needs to be updated, for one thing. I seem to remember I either didn't know how to fix the database, or I didn't have the required password. Possibly both. Also, the installed software needed updating -- texvc and memcached and all that. I was also put off by a long network lag. It was all very annoying, so I basically stopped developing until I had my own test server.
-- Tim Starling.
On Thursday, Oct 30, 2003, at 17:26 US/Pacific, Tim Starling wrote:
There are a fair few sorely needed features which won't slow down there server. For example, a warning when people overwrite images, or the ability to access the source of protected pages.
True enough; these are "bite-sized" and would be nice to have. Furthermore they "should" be fairly simple. :)
Lee's server is still around, although it's a bit broken. The database schema needs to be updated, for one thing. I seem to remember I either didn't know how to fix the database, or I didn't have the required password. Possibly both. Also, the installed software needed updating -- texvc and memcached and all that. I was also put off by a long network lag. It was all very annoying, so I basically stopped developing until I had my own test server.
I'll take a look at it, but I may not have the necessary permissions either. I haven't touched it a long time, since I use my own local test server.
-- brion vibber (brion @ pobox.com)
"TS" == Tim Starling ts4294967296@hotmail.com writes:
TS> However, I'm certainly not doing new features at the moment -- TS> it's been far too long since the branches were last merged, so TS> I'm working on cleaning up the unstable branch, not TS> optimisation.
So, this is kind of a non-sequitur, and a response to a really old post, and pretty much a commercial for some good Free Software. But, anyways...
I've noticed that it's really hard keeping unstable and stable in synch. I know that that's hard -- doing any branching and merging in CVS is hard.
I just want to put the flea in anybody who's listening's ear about GNU arch.
http://www.gnu.org/software/gnu-arch/ http://gnuarch.org/bin/view/Main/WhyArch
Arch has some features that are really great for distributed development teams like MediaWiki's:
* Distributed repositories: individual developers can have their own repositories, so they can do incremental version control, and then push or pull stuff from a central repository.
* Pull-based distribution: few people have to have write access to the central repository. A source monitor can pick and choose changes from remote repositories. In other words, no more patch files.
* Extremely graceful branching and merging: Branching and merging in arch is a delight. It works. It really works. Conflicts are rare and easy to resolve. Repeated merges (merging between branches more than once) is handled automatically and cleanly.
* Project-based change management: versioning is done by the project directory, not by individual files. (You can check in individual files if you want to, though.)
* Automated Changelog generation: arch can make and version GNU-style changelogs automatically.
* Multiple access protocols: arch can use HTTP, WebDAV, sftp, ftp, NFS, and some other protocols for remote access (read-only or read-write). A combination of sftp (for developers needing write access) and HTTP (for people needing only read access) works great with SourceForge.
arch is stable software, written in C (old versions were shell + utils, but it's all C now).
MediaWiki is the first project I've worked on using CVS in over a year. I've been using arch since then, and I have to tell you: CVS is really painful after spending time with arch. I keep a private arch repository for Wikitravel-specific changes to MediaWiki.
I realize that changing version control systems probably isn't at the top of anyone's TODO list. I just want to put it out there that there's an easier and cleaner tool than CVS.
~ESP
On Nov 28, 2003, at 18:14, Evan Prodromou wrote: [suggests 'arch' for source control instead of cvs]
Could we import our existing CVS repository with history, or would we have to break everything (again) at that point?
-- brion vibber (brion @ pobox.com)
"BV" == Brion Vibber brion@pobox.com writes:
BV> Could we import our existing CVS repository with history, or BV> would we have to break everything (again) at that point?
AFAIK, there's no dependable CVS import tool. It's just too hard -- CVS does such a crap job of tracking branches and merges, there's just too much guesswork.
Or so I've heard. I'd never want to write one, that's for sure.
Last I checked, the arch party line was: just keep your CVS repository around if you need it. The history is stored there.
~ESP
How about subversion? I don't know what the limitations on the import process are. None, apparently.
http://svnbook.red-bean.com/html-chunk/apb.html
Russell
Brion Vibber wrote:
On Nov 28, 2003, at 18:14, Evan Prodromou wrote: [suggests 'arch' for source control instead of cvs]
Could we import our existing CVS repository with history, or would we have to break everything (again) at that point?
-- brion vibber (brion @ pobox.com)
Wikitech-l mailing list Wikitech-l@Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Would it be possible to automatically create an alphabetical list of wikipedia entries/articles? This is available in many electronic encyclopedia and would make searching easier.
Cheers,
Jurriaan
At 18:08 04/12/2003 +0100, you wrote:
Would it be possible to automatically create an alphabetical list of wikipedia entries/articles? This is available in many electronic encyclopedia and would make searching easier.
Cheers,
Jurriaan
I am just writing a search index and had also thought of something similar so will add something. Please add comments / what you would like to my user page on http://meta.wikipedia.org/wiki/User:Archivist
Dave Caroline
aka archivist
IWikitech-l mailing list Wikitech-l@Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On Fri, 2003-10-31 at 00:59, Brion Vibber wrote:
On Thursday, Oct 30, 2003, at 16:36 US/Pacific, Chris Seaton wrote:
I tried to start developing, but found myself largely ignored. I asked for suggestions as to where to start, what were the areas that needed work, but was just vaguely pointed towards the bug reports.
If someone had said you can do X - something attainable within a few hours - I would have probably been hooked.
What we need are bug fixes and performance improvements.
What we need are developers. To do that you have to get people interested. When I asked what I could do and people sent me to the bug reports page it was like starting dumping a pile of work on my desk. I didn't know where to start.
Unfortunately this isn't very sexy; you need to have some familiarity with the code to understand how it works and track down the bits that don't work right or don't run well, and that's work:
http://meta.wikipedia.org/wiki/Development_tasks
Instead, newcomers tend to want to add sexy new features that scratch their personal itches. These can be neat, but they also introduce new bugs and new slowdowns. We don't need new features right now. We need ugly, unpleasant grunt work that no one wants to do.
And it won't get done unless people encourage new developers.
I made one commit to CVS, but it still hasn't gone onto the English Wikipedia (it was only one line).
We're *all* overworked. If something isn't getting done, you have to either do it yourself or speak up. In this case, speak up.
My pointers:
- Be very enthusiastic when someone comes forward
- Give them something to get hooked on
- Access to a test server
A public test server that won't wipe out our live server if something goes wrong would be great. Who wants to set that up? Lee at least did provide access to his server for this purpose, I don't know if that's still going on.
-- brion vibber (brion @ pobox.com)
Wikitech-l mailing list Wikitech-l@Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
A public test server that won't wipe out our live server if something goes wrong would be great. Who wants to set that up? Lee at least did provide access to his server for this purpose, I don't know if that's still going on.
-- brion vibber (brion @ pobox.com)
I have been given at ibiblio a test server but so far have just been trying to get a version of the more recent software to work, and have been stymied by the failure of the math to compile, but this could be used by the whole group if we agreed to it and that way I could get up to speed (as it would all presumably work on the ibiblio software.)
Actually I have two test servers, a dev and a prod one in addition to the one internet-encyclopedia runs on.
But they would probably just give you one of your own if you asked. (these are virtual servers)
Fred
Chris Seaton wrote:
On Fri, 2003-10-31 at 00:29, Tim Starling wrote:
Is there anyone out there who has considered contributing to the MediaWiki PHP script, but decided it against for reasons such as:
- Don't know PHP/MySQL
- Poor documentation, can't understand the code
- Wouldn't know where to start
- Don't have a test server
- Don't have CVS/server access, and you find contributing otherwise to
be tedious and frustrating
Or perhaps you've contributed on occasion but you're deterred from contributing again for reasons such as those above?
I know PHP, MySQL, CVS, HTML et cetera all to a reasonable standard, and thought you would all be gagging for me.
I tried to start developing, but found myself largely ignored. I asked for suggestions as to where to start, what were the areas that needed work, but was just vaguely pointed towards the bug reports.
If someone had said you can do X - something attainable within a few hours - I would have probably been hooked.
I made one commit to CVS, but it still hasn't gone onto the English Wikipedia (it was only one line).
That's why I gave up trying. Anyway, that was the summer holidays. Now I at Uni with much less free time.
My pointers:
- Be very enthusiastic when someone comes forward
- Give them something to get hooked on
- Access to a test server
Thanks Chris, your points are well taken. A few notes:
Pushing a feature right through to the live version currently takes a fair bit of work, and knowledge of our opaque development process. But seeing your feature hit the live version is a real buzz -- it makes the hard work worthwhile. Perhaps Brion and I could help out with getting new features up ASAP.
I found the lack of access to a test server very difficult when I was first starting. But giving people SSH access to larousse carries with it all sorts of security/trust implications. For example:
* The live scripts are readable by all, and often writeable by all. This includes the non-root database passwords. So as a result, anyone with SSH access to larousse also has full access to the en: database * All the server logs are readable by all.
This makes people with larousse access effective editorial administrators, capable of violating the privacy of editors in various ways.
Perhaps we could give people access to larousse, but not give them wikidev group membership -- instead give them a different group. Then we could carefully set up the permissions and groups so that these people have full access to the test database, the test script directory, the server log and the debug log for test, but not to the main database. We would also have to be careful with copies of LocalSettings.php in our home directories.
Tim Starling wrote:
Is there anyone out there who has considered contributing to the MediaWiki PHP script, but decided it against for reasons such as:
- Don't know PHP/MySQL
- Poor documentation, can't understand the code
- Wouldn't know where to start
- Don't have a test server
- Don't have CVS/server access, and you find
contributing otherwise to be tedious and frustrating
Or perhaps you've contributed on occasion but you're deterred from contributing again for reasons such as those above?
If so, please speak up! What areas could we improve to make it easier to contribute?
If you prefer, you can contact me privately at tstarlingphysicsunimelbeduau.
-- Tim Starling.
I tried to learn PHP because I wanted to help program MediaWiki, but I couldn't figure out how to configure Apache and the internet resources for it weren't good enough. LDan
__________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/
Daniel Ehrenberg wrote:
I tried to learn PHP because I wanted to help program MediaWiki, but I couldn't figure out how to configure Apache and the internet resources for it weren't good enough. LDan
On Windows? What if someone wrote an installation package, which installed and configured Apache, PHP and MediaWiki on Windows? Click next a few times and it thinks for a while then opens a browser window for you. Would that help?
And which internet resources did you mean: PHP, or Apache?
-- Tim Starling
--- Tim Starling ts4294967296@hotmail.com wrote:
Daniel Ehrenberg wrote:
I tried to learn PHP because I wanted to help
program
MediaWiki, but I couldn't figure out how to
configure
Apache and the internet resources for it weren't
good
enough. LDan
On Windows? What if someone wrote an installation package, which installed and configured Apache, PHP and MediaWiki on Windows? Click next a few times and it thinks for a while then opens a browser window for you. Would that help?
Yes, that would help.
And which internet resources did you mean: PHP, or Apache?
-- Tim Starling
I couldn't install PHP. LDan
__________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/
On Friday 31 October 2003 02:45, Daniel Ehrenberg wrote:
On Windows? What if someone wrote an installation package, which installed and configured Apache, PHP and MediaWiki on Windows? Click next a few times and it thinks for a while then opens a browser window for you. Would that help?
Yes, that would help.
And which internet resources did you mean: PHP, or Apache?
-- Tim Starling
I couldn't install PHP.
On Windows, I used certain Gefion Lite Web Server for PHP; it comes with PHP pre-installed.
Tim Starling wrote:
On Windows? What if someone wrote an installation package, which installed and configured Apache, PHP and MediaWiki on Windows? Click next a few times and it thinks for a while then opens a browser window for you. Would that help?
Would help me. I've got Apache and PHP running here, but I couldn't get MediaWiki functional. I mean, I made /progress/, and got it to display different errors as various things were fixed (not easy, I don't know Apache or PHP), but no go. If I can get MediaWiki running on my box, I'd be able to really start hacking at it and figuring out its innards (learning PHP as I go, but hey, that's how I always learn languages).
-- Jake
Yes, same here. I have apache and PHP running on FreeBSD, and I had lots of trouble getting Wikimedia installed using the install.php script that it comes with. I have heard that it may be buggy, so I am waiting maybe for a newer release, or until Brion may reply to this email :)
Thanks, Pedram
I go by 'kerx' on freenode, and lurk around #wikipedia every so often, or you can usually catch me on #c #ai or #math.
-----Original Message----- From: wikitech-l-bounces@Wikipedia.org [mailto:wikitech-l-bounces@Wikipedia.org] On Behalf Of Jake Nelson Sent: Friday, October 31, 2003 12:01 AM To: Wikimedia developers Subject: Re: [Wikitech-l] Re: Need developers
Tim Starling wrote:
On Windows? What if someone wrote an installation package, which installed and configured Apache, PHP and MediaWiki on Windows? Click next a few times and it thinks for a while then opens a browser window for you. Would that help?
Would help me. I've got Apache and PHP running here, but I couldn't get MediaWiki functional. I mean, I made /progress/, and got it to display different errors as various things were fixed (not easy, I don't know Apache or PHP), but no go. If I can get MediaWiki running on my box, I'd be able to really start hacking at it and figuring out its innards (learning PHP as I go, but hey, that's how I always learn languages).
-- Jake
_______________________________________________ Wikitech-l mailing list Wikitech-l@Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On Friday, Oct 31, 2003, at 00:29 US/Pacific, Pedram Messri wrote:
Yes, same here. I have apache and PHP running on FreeBSD, and I had lots of trouble getting Wikimedia installed using the install.php script that it comes with. I have heard that it may be buggy, so I am waiting maybe for a newer release, or until Brion may reply to this email :)
Well, I never use the install script personally so I can't guarantee anything about it. I would appreciate some details on the error messages though, hopefully it can be resolved.
I posted some manual install instructions on mediawiki-l a couple weeks ago: http://mail.wikipedia.org/pipermail/mediawiki-l/2003-October/000004.html
One of my test boxes is running FreeBSD 5.1, and things generally work. I've got apache 2 installed from ports, and PHP installed from source with some extra options. The only trouble I recall having has been with TeX; texvc itself compiles (ocaml is conveniently in ports/devel) but something fails in the series of things that get called to produce output from the wiki.
-- brion vibber (brion @ pobox.com)
Tim Starling wrote:
On Windows? What if someone wrote an installation package, which installed and configured Apache, PHP and MediaWiki on Windows? Click next a few times and it thinks for a while then opens a browser window for you. Would that help?
Yes! Yes! Yes!
For Windows users confused by WinCVS, I REALLY recommend http://www.tortoisecvs.org/ It's fantastic!!!!!!
tarquin wrote:
For Windows users confused by WinCVS, I REALLY recommend http://www.tortoisecvs.org/ It's fantastic!!!!!!
Yep. I use it too on my windows machines. It integrates very well with the explorer, no "classical" stand-alone application needed.
Magnus
On Friday, Oct 31, 2003, at 03:27 US/Pacific, tarquin wrote:
Tim Starling wrote:
On Windows? What if someone wrote an installation package, which installed and configured Apache, PHP and MediaWiki on Windows? Click next a few times and it thinks for a while then opens a browser window for you. Would that help?
Yes! Yes! Yes!
This seems a popular idea. Does anyone want to claim this task? (I have no experience using these things on Windows.)
For Windows users confused by WinCVS, I REALLY recommend http://www.tortoisecvs.org/ It's fantastic!!!!!!
Incidentally, I once tried to try out MacCVS, which is the same thing as WinCVS but the Mac version. My eyes glazed over and I quickly went back to the comfort of my carefully memorized handful of command-line sigils. So I feel your pain. :)
If TortoiseCVS is as handy as the screenshot looks, that looks *awesome*.
-- brion vibber (brion @ pobox.com)
"Brion Vibber" brion@pobox.com wrote in message news:A17F0007-0BDF-11D8-BCB7-000A95DAA284@pobox.com...
On Friday, Oct 31, 2003, at 03:27 US/Pacific, tarquin wrote:
Tim Starling wrote:
On Windows? What if someone wrote an installation package, which installed and configured Apache, PHP and MediaWiki on Windows? Click next a few times and it thinks for a while then opens a browser window for you. Would that help?
Yes! Yes! Yes!
This seems a popular idea. Does anyone want to claim this task? (I have no experience using these things on Windows.)
I could probably handle it, and I gather Magnus could as well. I'm not sure where to put it on my priorities list, though. And I'm also not sure of the feasibility -- it depends on how hard it is to automate the installation process of the individual packages. My basic idea is to only allow installation onto a system with none of the constitutent packages installed. So the installation process would consist of installing the constituent packages, then simply overwriting the configuration files with pre-prepared ones.
For Windows users confused by WinCVS, I REALLY recommend http://www.tortoisecvs.org/ It's fantastic!!!!!!
Incidentally, I once tried to try out MacCVS, which is the same thing as WinCVS but the Mac version. My eyes glazed over and I quickly went back to the comfort of my carefully memorized handful of command-line sigils. So I feel your pain. :)
If TortoiseCVS is as handy as the screenshot looks, that looks *awesome*.
Yeah, it's great. I was disappointed when I installed Linux and attempted to find something similar on that platform. gcvs is pretty useless compared to TortoiseCVS.
-- Tim Starling.
Tim Starling wrote:
Is there anyone out there who has considered contributing to the MediaWiki PHP script, but decided it against for reasons such as:
- Don't know PHP/MySQL
Am learning. Professional db dev with MYSQL2k, ASP, Python. PHP not hard.
- Poor documentation, can't understand the code
Yes.
- Wouldn't know where to start
- Don't have a test server
Yes.
- Don't have CVS/server access, and you find
contributing otherwise to be tedious and frustrating
Yes.
Or perhaps you've contributed on occasion but you're deterred from contributing again for reasons such as those above?
No. Deterred before contributing.
If so, please speak up! What areas could we improve to make it easier to contribute?
Docs. Good commenting of the code. A SINGLE document that details all aspects of the development and code. (It's hard when you have to go fishing and you're never sure if you got it all, or the latest.
Maybe to a wiki for the code... Imagine that, a wiki at the W!
Instructions and downloadables for Apache+php+mySQL on Win2k.
A visual cvs a la mozdev.
===== Christopher Mahan chris_mahan@yahoo.com 818.943.1850 cell http://www.christophermahan.com/
__________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/
--- Christopher Mahan chris_mahan@yahoo.com wrote: Previous post, MYSQL2k should be MSSQL2k ... Woah, what a slip of the finger...
===== Christopher Mahan chris_mahan@yahoo.com 818.943.1850 cell http://www.christophermahan.com/
__________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/
Tim Starling wrote:
Is there anyone out there who has considered contributing to the MediaWiki PHP script, but decided it against for reasons such as:
- Don't know PHP/MySQL
Yes, but this would a good excuse to learn it. Poring over raw object files all day can get tiresome... :-)
- Poor documentation, can't understand the code
- Wouldn't know where to start
Yes.
- Don't have a test server
Presumably I could set one up on one of my machines? A chance to see if OS X lives up to its billing... :-)
But my chief obstacle will be that I need to get Apple to relinquish rights to any MediaWiki code I write - my current list of exempted projects predates WP!
In the meantime I can start fooling around, although it will steal from content creation cycles...
Stan
On Thursday, Oct 30, 2003, at 17:23 US/Pacific, Stan Shebs wrote:
- Don't have a test server
Presumably I could set one up on one of my machines? A chance to see if OS X lives up to its billing... :-)
MediaWiki does run on my PowerBook (under 10.2, I haven't installed Panther yet) with the stock Apache and PHP installed from source. I haven't tried messing with TeX yet, though.
(There could conceivably be problems with case-insensitivity in the HFS+ filesystem, but I haven't run into any yet. Most of our filesystem storage -- images and the html cache -- chops up the space by hashes... assuming the hashing puts out randomish results, and we're using 8 bits of that, we can expect to see 1/65536 of case-colliding names colliding in the filesystem.)
But my chief obstacle will be that I need to get Apple to relinquish rights to any MediaWiki code I write - my current list of exempted projects predates WP!
Oh, it's okay if they own the copyright to your contributions so long as they let them be GPL-licensed. :)
In the meantime I can start fooling around, although it will steal from content creation cycles...
Con...tent? Wait -- there's *text* is this here wiki thing!
-- brion vibber (brion @ pobox.com)
Is there anyone out there who has considered contributing to the MediaWiki PHP script, but decided it against for reasons such as:
- Don't know PHP/MySQL
- Poor documentation, can't understand the code
- Wouldn't know where to start
- Don't have a test server
- Don't have CVS/server access, and you find contributing otherwise to
be tedious and frustrating
Or perhaps you've contributed on occasion but you're deterred from contributing again for reasons such as those above?
If so, please speak up! What areas could we improve to make it easier to contribute?
If you prefer, you can contact me privately at tstarlingphysicsunimelbeduau.
-- Tim Starling.
The lack of comments on what the purpose of most of the code is pretty much precludes almost anyone who didn't write it from participating. All changes together with comments should also be dated.
Fred
On Thu, 30 Oct 2003, Fred Bauder wrote:
The lack of comments on what the purpose of most of the code is pretty much precludes almost anyone who didn't write it from participating. All changes together with comments should also be dated.
Same argument here: when writing my toy wiki parser, I checked out phaseIII software from CVS to get ideas from the code. I was amazed at the lack of comments - given a target to search for, finding the right bit is very time-consuming, unless you already know where to look at. (disclaimer: I'm not a PHP expert, but I thought that I could parse it quite well)
Ciao, Alfio
On Friday, Oct 31, 2003, at 02:44 US/Pacific, Alfio Puglisi wrote:
On Thu, 30 Oct 2003, Fred Bauder wrote:
The lack of comments on what the purpose of most of the code is pretty much precludes almost anyone who didn't write it from participating. All changes together with comments should also be dated.
Same argument here: when writing my toy wiki parser, I checked out phaseIII software from CVS to get ideas from the code. I was amazed at the lack of comments - given a target to search for, finding the right bit is very time-consuming, unless you already know where to look at. (disclaimer: I'm not a PHP expert, but I thought that I could parse it quite well)
A great project for someone who'd like to get into MediaWiki development would be going through the code and documenting it, asking "what the HECK does this spaghetti code do?" to the list whenever needed.
Not only would this be a great learning exercise, but it should help identify a lot of problem spots with dead, duplicated, or dangerous code.
In addition to the missing in-code documentation, there's some meagre docs on meta that need to be beefed up: http://meta.wikipedia.org/wiki/MediaWiki_architecture
-- brion vibber (brion @ pobox.com)
On Friday 31 October 2003 01:29, Tim Starling wrote:
Is there anyone out there who has considered contributing to the MediaWiki PHP script, but decided it against for reasons such as:
- Don't have CVS/server access, and you find contributing otherwise to
be tedious and frustrating
I wanted to contribute to this and several other open source programs, but "ease of use" of CVS drove me off. For some reason, I *hate* CVS, even updating from it, and I have never even tried getting CVS access and commiting anything. I'm particulary mad at KDE for there one must download a whole package of programs or even two in order to work on only one program. And then when I do something I end up with possibly unstable copy of the program for myself or not using my features until a stable copy is released.
By the way, I installed MW at my computer, and the first thing I had to do was to put @ in front of each is_file and is_dir. Maybe there's something wrong with my PHP settings, but perhaps that should be done in the main sourceas well.
Tim Starling wrote:
- Don't know PHP/MySQL
- Poor documentation, can't understand the code
- Don't have a test server
Yes to the above.
Or perhaps you've contributed on occasion but you're deterred from contributing again for reasons such as those above?
Not having test server is the main problem. I can use CVS to a certain extent, but when Brion started talking about "branches" I was completely lost :(
I would still like to work on a new template system, but not having a test server is a problem. Also, the *endless* logo votes and debates are not encouraging -- the idea that new site design would be subject to the same sort of thing is really not encouraging
Is there anyone out there who has considered contributing to the MediaWiki PHP script, but decided it against for reasons such as: [...] Or perhaps you've contributed on occasion but you're deterred from contributing again for reasons such as those above?
If so, please speak up! What areas could we improve to make it easier to contribute?
Tim, Everyone,
Your list of objections seems to sort of miss the mark so I thought I'd share some ideas.
- Don't know PHP/MySQL
PHP and MySQL, though not particularly common, are simple enough that anyone with a reasonably strong background in things like Perl, Java, and other SQL database should have little difficulty with them.
- Poor documentation, can't understand the code
I don't get it. The code is simple. The Wikimedia server is not nearly big enough, or complicated enough, to pose much of a challenge or obstacle for people who have the background. By that I mean, that people who know HTML, Apache, SQL, OOP, and the basics of data-driven web site operation -- it's straightforward.
- Don't have a test server
Well, it has been run with minimal changes now on Apple, Windows, and Linux environments. For functional changes, that's a sufficient environment for development and preliminary testing.
- Don't have CVS/server access, and you find contributing otherwise to
be tedious and frustrating
Since the project is CVS readable to the world, I don't think this is germane.
- Wouldn't know where to start
Yes, that's part of it.
---
The first obstacle, for me, is motivation. After twenty years of writing code the novelty has worn off (though I still enjoy what I do) and I only write software for the best of reasons. In most cases these reasons involve money. Now, I'm willing to volunteer my time and talents, but it better be fun, or for some sort of just cause or greater good, or have some sort of non-financial reward involved.
The Wikimedia software needs work like profiling, tuning, index analysis, and careful analysis of performance issues. It needs implementation of fiddly things like deletion management and automated software installation, and some basic, boring maintenance and bugfixing. These are not particularly fun tasks as development goes, which should be unsurprising, because there are plenty of volunteers for the high-level architecture, initial implementation of sexy features, and the like.
Now, developers at Wikipedia, as a rule, don't get much in return for their efforts. They don't get any greater input into policy discussions than anyone else, they don't get any real special access or anything, and they don't get particularly much in the way of credit, fame, or job leads.
To some extent these motivational problems are present on any open-source project, though they seem particularly acute at Wikimedia since the software is not a good candidate for reuse for other projects, given that UseModWiki is the most frequent choice.
So, what to do?
First, a greater recognition of the odious yet important nature of some of the tasks.
Second of all, it would help to publicize software development credits more prominently on the site.
Third, some sort of remuneration, even if token and noncash, would be helpful. Maybe we could start with a gift registry, and people could send boxes of fancy fruit, expensive scotch, and candy to their favorite developer. Or raffle off a free winter vacation for two to some sunny island villa. Or just pay a small hourly stipend for development work, even if it is only a fraction of the market rate.
--
Louis
Louis Kyu Won Ryu wrote:
Is there anyone out there who has considered contributing to the MediaWiki PHP script, but decided it against for reasons such as: [...] Or perhaps you've contributed on occasion but you're deterred from contributing again for reasons such as those above?
If so, please speak up! What areas could we improve to make it easier to contribute?
Tim, Everyone,
Your list of objections seems to sort of miss the mark so I thought I'd share some ideas. [...] The first obstacle, for me, is motivation. After twenty years of writing code the novelty has worn off (though I still enjoy what I do) and I only write software for the best of reasons. In most cases these reasons involve money. Now, I'm willing to volunteer my time and talents, but it better be fun, or for some sort of just cause or greater good, or have some sort of non-financial reward involved.
The Wikimedia software needs work like profiling, tuning, index analysis, and careful analysis of performance issues. It needs implementation of fiddly things like deletion management and automated software installation, and some basic, boring maintenance and bugfixing. These are not particularly fun tasks as development goes, which should be unsurprising, because there are plenty of volunteers for the high-level architecture, initial implementation of sexy features, and the like.
Now, developers at Wikipedia, as a rule, don't get much in return for their efforts. They don't get any greater input into policy discussions than anyone else, they don't get any real special access or anything, and they don't get particularly much in the way of credit, fame, or job leads.
To some extent these motivational problems are present on any open-source project, though they seem particularly acute at Wikimedia since the software is not a good candidate for reuse for other projects, given that UseModWiki is the most frequent choice.
So, what to do?
First, a greater recognition of the odious yet important nature of some of the tasks.
Second of all, it would help to publicize software development credits more prominently on the site.
Third, some sort of remuneration, even if token and noncash, would be helpful. Maybe we could start with a gift registry, and people could send boxes of fancy fruit, expensive scotch, and candy to their favorite developer. Or raffle off a free winter vacation for two to some sunny island villa. Or just pay a small hourly stipend for development work, even if it is only a fraction of the market rate.
Not everyone has 20 years of programming experience. Many potential Wikipedia developers don't have that kind of skill level. That doesn't mean they don't have a useful contribution to make. And their skill will increase over time, as they work with us.
A number of people have posted messages saying that my list of objections were reasonably close to their own reasons for not contributing. I don't intend to tell them all that they should go get a decade of experience and come back later, I intend to do my best to address their concerns.
As for financial incentives: let's just say opinions are divided. Maybe if Louis pushed it for long enough, and made a good enough case, it might happen. But I think there's a fairly large potential labour pool who will work for nothing (except for a bit of support).
Extra recognition sounds nice. It wouldn't be hard to increase the prominence of software credits -- it is a wiki after all. I won't do it myself though -- that would kind of defeat the purpose in emotional terms.
-- Tim Starling.
Tim Starling wrote:
Not everyone has 20 years of programming experience. Many potential Wikipedia developers don't have that kind of skill level. That doesn't mean they don't have a useful contribution to make. And their skill will increase over time, as they work with us.
I couldn't agree more and was only trying to make a point about motives for software development varying among experience groups.
IMO, actual technical skill in writing software, troubleshooting, and so forth doesn't really increase much after the first three or four years of experience. At that point skill is determined more by aptitude, environment knowledge and project-specific knowledge. Ancillary skills such as estimating, requirements analysis, teamwork, and the like do however continue to accrue with time.
As for financial incentives: let's just say opinions are divided. Maybe if Louis pushed it for long enough, and made a good enough case, it might happen. But I think there's a fairly large potential labour pool who will work for nothing (except for a bit of support).
The likelihood of anything happening at Wikipedia because "Louis pushed it for long enough" is remote enough to be mirthsome.
One of the things that occured to me after I sent the post was that pay, even if token, would allow volunteers to include their work for Wikipedia on a resume or job application more credibly if they wished to do so.
Louis
Tim Starling wrote:
Is there anyone out there who has considered contributing to the MediaWiki PHP script, but decided it against for reasons such as:
- Don't know PHP/MySQL
- Poor documentation, can't understand the code
- Wouldn't know where to start
- Don't have a test server
- Don't have CVS/server access, and you find contributing otherwise to
be tedious and frustrating
Or perhaps you've contributed on occasion but you're deterred from contributing again for reasons such as those above?
If so, please speak up! What areas could we improve to make it easier to contribute?
If you prefer, you can contact me privately at tstarlingphysicsunimelbeduau.
-- Tim Starling.
I suppose that it will be usefull if someone try to update the status of all the bugs entries on sourceforge. If so then I'm volonteer for this; it will be a good exercice!
-- Looxix
Luc Van Oostenryck wrote:
I suppose that it will be usefull if someone try to update the status of
all the
bugs entries on sourceforge. If so then I'm volonteer for this; it will be a good exercice!
-- Looxix
Most of the entries in the bug tracker are tedious, minor problems that the other developers have put into their "delay indefinitely" basket. If that's what you want to do, then I wish you well. But you may well be better off fixing the problems identified by developers, rather than users. Brion's MediaWiki to-do list is at:
http://meta.wikipedia.org/wiki/Development_tasks
That page mainly has decent sized projects. By my judgement, most of them require a day or more. My current scratch pad is:
http://meta.wikipedia.org/wiki/Development_status
This contains some significant, fairly easily fixed bugs with the unstable branch. These bugs are currently preventing the unstable branch from becoming stable. It's been a few months since the unstable branch was last merged with stable, much to the annoyance of people like Chris Seaton, who find their code makes its way to the live version exceedingly slowly. There's also a list of new features which need some more testing, preferably by a different set of eyes.
Have you got your own test server?
-- Tim Starling.
Tim Starling wrote:
Luc Van Oostenryck wrote:
I suppose that it will be usefull if someone try to update the status of
all the
bugs entries on sourceforge. If so then I'm volonteer for this; it will be a good exercice!
-- Looxix
Most of the entries in the bug tracker are tedious, minor problems that the other developers have put into their "delay indefinitely" basket. If that's what you want to do, then I wish you well. But you may well be better off
Yes I have seen. Somes are "nice to have"/"features request", somes are probably resolved, other are unreproducible.
fixing the problems identified by developers, rather than users. Brion's MediaWiki to-do list is at:
http://meta.wikipedia.org/wiki/Development_tasks
That page mainly has decent sized projects. By my judgement, most of them require a day or more. My current scratch pad is:
http://meta.wikipedia.org/wiki/Development_status
This contains some significant, fairly easily fixed bugs with the unstable branch. These bugs are currently preventing the unstable branch from becoming stable. It's been a few months since the unstable branch was last merged with stable, much to the annoyance of people like Chris Seaton, who find their code makes its way to the live version exceedingly slowly. There's also a list of new features which need some more testing, preferably by a different set of eyes.
Yes, I hav eseen these pages, but I don't know the code yet (and PHP also). I will look at it this WE.
Have you got your own test server?
My own PC, with wikimedia installed and more or less working.
-- Tim Starling.
-- Looxix
"TS" == Tim Starling ts4294967296@hotmail.com writes:
LVO> I suppose that it will be usefull if someone try to update LVO> the status of all the bugs entries on sourceforge. If so LVO> then I'm volonteer for this; it will be a good exercice!
TS> Most of the entries in the bug tracker are tedious, minor TS> problems that the other developers have put into their "delay TS> indefinitely" basket. If that's what you want to do, then I TS> wish you well. But you may well be better off fixing the TS> problems identified by developers, rather than users.
So, I read this a while ago, and it kinda clicked for me this afternoon as I was going through the SourceForge bugs.
I think it would be an excellent task for someone just getting into MediaWiki to update status on bugs and RFEs on SourceForge, merge some together, remove assignments to inactive developers, and generally keep that whole mess up to date.
~ESP
"EP" == Evan Prodromou evan@wikitravel.org writes:
EP> I think it would be an excellent task for someone just getting EP> into MediaWiki to update status on bugs and RFEs on EP> SourceForge, merge some together, remove assignments to EP> inactive developers, and generally keep that whole mess up to EP> date.
I just got developer access, I seem to be unable to edit any bugs. Can somebody flip the switch that says I can close bugs that get fixed?
~ESP
P.S. I just committed the patches for hide-minor-edits and for redirecting cookie checks.
On Nov 29, 2003, at 10:46, Evan Prodromou wrote:
I just got developer access, I seem to be unable to edit any bugs. Can somebody flip the switch that says I can close bugs that get fixed?
You've got to love a system that by default allows *anyone* to commit code and *no one* to mark bug reports as closed.
(flip flip flip) okay, let's see if that did it.
-- brion vibber (brion @ pobox.com)
"BV" == Brion Vibber brion@pobox.com writes:
BV> You've got to love a system that by default allows *anyone* to BV> commit code and *no one* to mark bug reports as closed.
Yay, SourceForge.
BV> (flip flip flip) okay, let's see if that did it.
Seems to be working. I'm trying to take out the bugs I fixed -- assigning them to myself in the process -- and combine some of the duplicate bugs and RFEs. It might make the list a little more manageable.
~ESP
On Nov 29, 2003, at 10:46, Evan Prodromou wrote:
P.S. I just committed the patches for hide-minor-edits and for redirecting cookie checks.
Great, thanks!
I fixed a slight bug in recentchanges which sometimes made the 'hide minor edits' link not work, and added some paranoid checks on the value of the hideminor variable.
And while I was there, I special-cased the login code so it won't helpfully return you to Special:Userlogout if you don't click another link after switching accounts...
-- brion vibber (brion @ pobox.com)
"BV" == Brion Vibber brion@pobox.com writes:
BV> Great, thanks!
BV> I fixed a slight bug in recentchanges which sometimes made the BV> 'hide minor edits' link not work, and added some paranoid BV> checks on the value of the hideminor variable.
Cool. I realize that I was a little overzealous in passing around the hideminor variable -- it probably doesn't need to be passed through if it's the same as the user's default.
BV> And while I was there, I special-cased the login code so it BV> won't helpfully return you to Special:Userlogout if you don't BV> click another link after switching accounts...
Nicely!
~ESP
wikitech-l@lists.wikimedia.org