Moodle Bugathon!

Moodle Bugathon!

by Martin Dougiamas -
Number of replies: 20
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

I've been talking about this for a while and it's time to get it rolling!


I'd like to have a bugathon for the next few months to:

- fix as many outstanding Moodle problems as possible
- raise awareness of the tracker and our development processes
- have some fun and give out some prizes!

I've got some details below, but if you have suggestions for additions/alterations let me know here so I can adjust them before the official launch.


Moodle Bugathon #1 (draft rules)

Start: Monday, November 12th
End: Tuesday, February 12th (3 months later)

There will be prizes in various categories. To let us know you're competing (and to be eligible for a prize) you should submit your own name to the Bugathon page in Moodle Docs (not created yet). Developers currently employed by Moodle HQ are not eligible for prizes but will be competing anyway. smile

I reserve the right to disallow someone if it becomes obvious they are cheating the system (eg by filing fake reports, setting up fake accounts, reassigning bugs from other people after they are done etc)

Note in all this I'm referring to bugs specifically (ie problems that need fixing) and not wider issues like feature requests! (We'll get onto those again once we clean up some of these bugs)

Some general documentation about the tracker.

1. MOST BUGS RESOLVED

The first person to attach a stable patch to a bug in the tracker, or submit a correctly-labelled-and-merged fix to CVS is deemed to be the resolver of a bug. Resolved bugs must be verified by an independent QA tester to be counted.

Points are assigned like this: 5 points for every bug + 1 point for every VOTE on that bug (so everybody vote for your favourite bugs!)

Developers should keep track of the bugs they fix in the Bugathon wiki page (official developers can generate this from the tracker itself, but others will have to maintain it manually).

Prizes:
  • #1 Developer: AU$1000 (approx $US940)
  • #2 Developer: AU$500
  • #3 Developer: AU$250
  • Next 5 Developers: Choice of any item from the Moodle Shop
  • Any other developer who fixes more bugs than the best-performing Moodle HQ programmer can get something from the Moodle Shop too. smile

2. MOST FIXES VERIFIED

To join the testing group in the tracker, email Michael Blake at support@moodle.com so he can add you.

This allows you to assign yourself as a QA person for any bug. After testing that a "Resolved" bug actually is fixed or works as the developer reported, you should change the status to Closed and make a comment on the bug to say what you saw.

Keep track of the bugs you've verified in the Bugathon wiki page (this is easy to generate from the tracker).

Prizes:
  • First prize: AU$250
  • Second prize: AU$100
  • Third prize: Choice of any item from the Moodle Shop

3. MOST DUPLICATES IDENTIFIED

If you find a bug that is the same as another bug (read them very carefully to make sure because sometimes this is deceptive) then create a new link between the two bugs marking the later one as a DUPLICATE. If you can, close the later bug too.

You'll need to keep a list of your duplicate bugs in the wiki to collect the prize (there is not a way to generate this info from the tracker, unfortunately).

Prizes:
  • First prize: AU$250
  • Second prize: AU$100
  • Third prize: Choice of any item from the Moodle Shop

4. MOST NEW BUGS FILED

New bugs are always welcome. Some people in our community are very good at finding them too, so this category is for them. Obviously bugs should be real fixable problems, and should not be duplicates of others already filed. All new bugs should contain full steps to reproduce the problem.

Keep track of the bugs you've filed in the Bugathon wiki (this is easy to generate from the tracker).

Prizes:
  • First prize: AU$250
  • Second prize: AU$100
  • Third prize: Choice of any item from the Moodle Shop

Average of ratings: -
In reply to Martin Dougiamas

Re: Moodle Bugathon!

by Séverin Terrier -
Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Testers Picture of Translators
Very good idea approbateur

A lot of people doesn't use uptodate Moodle version, and it's strange to see that some bugs are several versions and years old...

I just wanted to suggest to take time, after 1.9 release, to solve most of the (sometimes very old) bugs, before adding new code, and new bugs, working on Moodle 2.0.

Nice to see that you're in that way cool
Average of ratings: -
In reply to Martin Dougiamas

Re: Moodle Bugathon!

by Dan Poltawski -
*Watches bugs dry up in the tracker till next week ;)

Not sure how to achieve it, but it'd be good if we could find a way to churn through the old open bugs which are no longer relevant, won't fix or already fixed. It'll help the focus and we might find some long-standing bugs which can be fixed easily!
Average of ratings: -
In reply to Martin Dougiamas

Re: Moodle Bugathon!

by Ryan Smith -
Sounds like a good idea!

Hopefully someone can be a superstar and take care of all 113 of the HTML Editor bugs by replacing HTMLArea with a modern, up-to-date editor! wink
Average of ratings: -
In reply to Ryan Smith

Re: Moodle Bugathon!

by Martín Langhoff -
A new editor... full of new bugs to be discovered? Heh. Old code doesn't rot.
Average of ratings: -
In reply to Martín Langhoff

Re: Moodle Bugathon!

by Ryan Smith -
Both TinyMCE and FCKEditor are very robust and have very active user communities. I imagine they'd welcome Moodle moving to their product. Besides, I'm sure it would make our Mac Safari users happy that they can use a full featured editor! smile
Average of ratings: -
In reply to Martin Dougiamas

Re: Moodle Bugathon!

by Iñaki Arenaza -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Just a small question, so we can focus on the 'interesting' bugs. Shall we close bugs in 1.9 only, or should we backport them to other versions? Which ones? (I try to backport them downto 1.6 when possible, as there's still a lot of people running 1.6 and 1.7 ).

Saludos. Iñaki.

Average of ratings: -
In reply to Iñaki Arenaza

Re: Moodle Bugathon! (shar

by Séverin Terrier -
Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Testers Picture of Translators
I think it's always useful to backport corrections of bugs, because if the correction is known, it's bad not to backport it, and still find people reporting it on other versions sad

Backporting downto 1.6 seems to be a good approach, because it's still very used, and 1.6 is the last fast Moodle version, for people not interested in roles and all the new stuff, or having small technical capabilities (shared host, old server...).
Average of ratings: -
In reply to Séverin Terrier

Re: Moodle Bugathon! (shar

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
As a general rule we (Moodle HQ) try to backport fixes to the last 18 months of versions, even though it's a lot of extra work. This means back to 1.6 where possible (it isn't always possible). I'd recommend this for everyone doing 1.9 fixes, but if you can't then go back as far as you can.

1.9 and HEAD - crucial
1.8 - important
1.7 - would be good
1.6 - still worth doing

Judging by the first day response to the Bugathon Moodle.com are going to be spending all their time checking in other people's patches! surprise approve
Average of ratings: -
In reply to Martin Dougiamas

Moodle Bugs - Future users

by venkatesan iyengar -
Sorry for a long post. I am one of the moodle user from early v1.4 for my teaching without any support from my university. Recently I was trying to prescribe moodle for my university's distance education program (running mostly in humanities and social science subjects) with a well prepared power point presentation (thanks to many developers). Our university vice chancellor asked for further opinion from experts?! in our computer science department. To my surprise, within two days they submitted a report saying that there are hundreds of bugs in moodle (I think they must have simply checked the moodle tracker page, and I am sure they have not tested themselves) and so it is not stable and cannot be put in to use. I could not convince my university any further (because I do not belong to computer science department) and university decided to use Indian Postal Services to deliver materials (we could not afford the commercial offering from webCT). I know that the decision is wrong because our university would not be using all the features provided in the moodle.

I think the wrong decision was taken by concluding that more of bugs means unstable. This would not have happened, at least in my opinion, if moodle brings more confidence in users that their base platform is strong, stable, and bug free. I think many bugs are individual related and not repeated by many others. In this regard I suggest that the bugs can be taken up in the following two stages:

Stage 1 - Bugs that bothers 80 % of the users using just common features
Bugs of the mostly used modules/filters/activity/authentication-methods/installaitions should be taken up first and made zero bug and this could be made as Moodle Standard Platform/Base. This should be made to work with most commonly available webserver/mysql setting and these features must be made to work with most commonly used browsers and OS. This would bring confidence in at least 80% of users and these users may be convinced to use the same suggested settings to work with. This could properly advertised which no doubt would put more confidence in first time users and new entrants. These features should be the base for future releases so that upgrading would also be bug free. A time frame to do this may also be fixed.

Stage 2 - Bugs with newer technologies
The next stage is to look in to modules/filters/activities/authentication that uses cutting edge technologies like AJAX/SCORM2004/newer authentication procedures/payment methodologies etc. These users are technically more advanced and can handle situation themselves till the bugs are solved permanently.

Stage 3 can be individual setting related issues.

We need fix some priority to the reported bugs and work with them, instead of taking up all the bugs at the same time. Core developers of moodle can have a brain storming session to do this and publish their priority and go along the line.

I think it is not a loss to moodle that my university is not going for it, but it pains me that such a wonderful kit is not recognized by so called experts and these people rule this world
Average of ratings: -
In reply to venkatesan iyengar

Re: Moodle Bugs - Future users

by Eric Merrill -
Picture of Core developers Picture of Moodle HQ Picture of Peer reviewers Picture of Plugin developers Picture of Testers
Well a few things.

One of the big problems is not the number of bugs in tracker, but that you can't see the tracker for commercial offerings. Back when we were on WebCT, we submitted many many bugs, most of which were never fixed. Their tracker system likely contains hundreds or thousands of bugs.

It's impractical/impossible to expect 0 bugs in any semi-large section of code, even the core ones. This is just one of the facts of life about software.

A bug is a bug wether one person experiences it or everybody, and so many of the bugs listed in the tracker may only effect a very small handful of people, but it's still one bug none the less.


Also, there is naturally a order of priority. Not only do bugs have a priority in the tracker, but bugs that effect more people are more likely to get fixed, if only because more people see it and someone is more likely to correct it. Moodle HQ already does a good job of directing which bugs have a higher priority.

Reported bugs are normally not a good indication of software quality. Even so, Moodle does not have a particularly large number of bugs in any released version, the most in recent releases is 1.8 with 44. For a reference, MySQL has 240 open bus in their system.

Personally, it sounds to me like whoever wrote up this report is either generally opposed to non-commercial software for critical services or does not understand the dynamics of open source software, or at the very least a vary large software project. Sometimes people just don't like an option, and will push invalid technical reasons to block it, because they know they can.

-eric
Average of ratings: -
In reply to Eric Merrill

Re: Moodle Bugs - Future users

by Don Hinkelman -
Picture of Particularly helpful Moodlers Picture of Plugin developers
Dear Venkatesan,

Perhaps you should remind them that the best "experts" are the world's largest university, Open University UK, and countless other prominent schools who use Moodle everyday as their main elearning software. Why would they use it if it is not stable?

It is a case of your board not being familiar with open source platforms. As Eric says, WebCT contained "likely hundreds or thousands of bugs" that are not public. In open source, bug reporting and bug fixing is public. Why do Google and the largest internet giants of the world use Linux, when it was reported to have 985 bugs in 2004? Perhaps because Windows could have up to 30 bugs in each 1000 lines of code. XP has 40 million lines of code--more than 1.3 million potential bugs!

Here is our testimony, "In five years, the Moodle LMS at our school has never been hacked, never been attacked by viruses, and never, ever crashed." Can Microsoft say that?

Don Hinkelman
Sapporo Gakuin University
Average of ratings: -
In reply to Martin Dougiamas

Re: Moodle Bugathon!

by Richard Enison -

MD,

Aside from the cheating problem you've already mentioned (should be simple enough to check against the Tracker), the biggest problem I can see with it is: it turns all would-be bug fixers into competitors, so it will cut down on collaboration and cooperation. Two heads are better than one, unless they're competing!

RLE

Average of ratings: -
In reply to Richard Enison

Re: Moodle Bugathon!

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
Well, that's possible, but I suppose collaboration is what we normally do all the time and look at all the bugs. smile This is a bit of a experiment.
Average of ratings: -