In fact I hate PHPBT.
How I wish this project used bugzilla.
One of the Google SOC students is building a replacement for us.
Just use bugzilla. It's what we use at the OU, it has had huge amounts of development by the mozilla folks, who use it to manage a large open source project, so it works really well for that. It has great features for developers to manage thier bug lists.
I think the main reasons given are that a general purpose issue tracker would be useful for a lot of Moodle sites and that Bugzilla would (just as the current bug tracker does, imho) scare off a lot of people who would happily contribute to something a little less brutal.
I (and others) want something very well integrated with Moodle, using all the accounts, text filters, themes etc. Of course it will be integrated tightly into the new moodle.org in future.
I second that emotion.
Hopefully, it will be flexible enough to handle help desk type tickets, as well.
They do offer a free license for open-source projects.
Note: no affiliation with Atlassian...just a quite satisfied user of Confluence & Jira.
Sure! but that doesn't mean we can't steal some good bugtracker from out there. There's plenty in the PHP+MySQL+GPL space that we can evaluate and potentially use (and improve).
That's how I came to Moodle -- so it can't be a bad strategy actually everyone but you around here did the same... you are the exception!
We need to stick to the core business - producing the best online learning system we can, and not get side-tracked with sub-projects that will take time to reach maturity, and will need maintaining.
Bugzilla is good at helping the reporter describe a bug, enabling the developer to manage its life-cycle, and searching bugs. And phpBugTracker is not as bad as the above comments suggest...
Some suggestions for more useful student projects:
1. Evaluate the latest version of phpBugTracker. Investigate patches for its bigger shortcomings (my personal gripes, lack of "keywords" ala Bugzilla, and not displaying the bug summary in the page title.) Investigate plug-ins or other extensions for PHPBT to use external authentication systems, like Moodle. In short, contribute to PHPBT development.
2. Evaluate how Bugzilla can be integrated with Moodle, and re-themed.
3. Evaluate other bug-tracking systems.
4. Investigate/ improve the usability of PHPBT/ Bugzilla/ whatever for bug-reporters - are new users really scared by them?
Please, don't make the mistake of trying to re-invent the wheel.
When Humbolt university wanted to implement a much more trivial feature - an image gallery module - they did not reinvent the wheel. Instead they made a module that linked to Gallery 2. http://moodle.org/mod/forum/discuss.php?d=40030
That is the right approach to this sort of thing.
By all means expose some of the bugtracker features in a Moodle module (that's a really cool idea), but for heaven's sake keep an proper bug database as the backend so developers who need the power features can get at them. Tweaking it to allow single sign on would be great too.
Two weeks after taking over as quiz module maintainer, I have over 150 bugs assigned to me, and the bugtracker is barely sufficient to let me get on top of them. I am very sceptical that a student can knock up something better in 2 months.
Nick mentoned some buzilla features he misses. Top of my list are:
- Decent search. In partcular
- It defaults to basic search, which is completely useless, so it always takes me 2 clicks to get to the search form.
- It will only search 'substing' or 'regexp', whereas what is most useful is 'all of these words'.*
- The different boxes for controlling "Status:", "Resolution:", etc. do an OR search, whereas what you want is AND.
- The "Change several bugs at once" feature in bugzilla, which lets you prioritise or reassign bugs en-masse.
- When you mouse-over a link to another bug, bugzilla gives you a tooltip summarising that bug. Very useful for things like tracking bugs.
- When you change a bug, bugzilla tells you who it is sending email too. When you add a comment to a bug asking the reporter for more information, it is important to know whether the message has got through.
At the very least, I would be interested to see moodle.org running the latest version of PHPBT. It would be worth assessing how much better it has got in the last 4 years. Of course, I have no idea how easy it is to upgrade. And if we were running the latest version, and keeping it up to date, I could always fix the things that piss me off the most.
* It is possible to write that query "contains all the words 'quiz', 'calculated' and 'import'" as a regexp, but it is a very long regexp. Exercise for the reader.
I don't use the bug tracker to the extreme, so I won't say anything about it... but I am glad that John Boyd Dunlop re-invented the wheel so we have the pneumatic tires that we use today
Yes, of course I've looked into the new version of PHPBT, and the changes in the latest versions are minimal. It was "dead" for a couple of years and only revived fairly recently. Upgrading would not be easy anyway because our current version has a lot of hacks to fix the worst aspects of it, and if we did upgrade, we would still not have the features we wanted (and have a lot of stuff we didn't need).
The path I'm taking now is actually the smallest amount of work for core developers. The work is being funded by Google, all we need to is guide that student doing the work (he was already doing something like it for his University administration *anyway*).
The core of a bug tracker is simply a single table of bug reports, and Moodle already provides all the authentication, email, text processing etc, so it's not going to be rocket surgery. I think it should be easily possible to accomodate development of the type of reports and data we all want to see.
So if you want to help build up the specifications wish-list that would be grand, the wiki (http://docs.moodle.org/en/Student_projects/Integrated_bug_tracker) is the place for that.
Instead, if we pick a good Bugtracker with a life of its own (passionate community, strong leader, etc), we don't have to move it forward. It moves forward naturally, and we'll reap the rewards of being part of a larger community.
This is exactly the case for Moodle over in-house LMSs, BTW -- we are all here because we decided to not build our own.
Martin D., I made remarks several months ago about the abysmal state of finding/tracking modules. I suggested a moodleforge style site for modules, you said no, something much better is coming (rolling your own)....needless to say, I'm still waiting...
I understand you concerns about integration, etc, but working, nudging another codebase in a direction that makes it compatible with moodle is much more desireable than rolling your own, and then expecting/hoping someone else will pick up the maintenance because you want to get back to coding on your LMS
Finally, a very nice bug-tracker that I played with a few months back is Eventum (mysql develops and uses it). Lots of nifty features, good integration points and devs are open to adding more integration points.
Moodle modules is an autolink phrase to it.
It's an improvement, but I'm still not seeing how this helps developers much...
Where's the integration to an SCM tool and bug tracking system?
I feel like the grinch here, but I still don't see why module developers can't have one easy to use place that addresses all their needs that comes with a tool like GForge, etc?
Integration is nice to have, but if it comes down to functionality vs integration for me, functionality wins. Particularly when we are talking about developers. Your average user is not going to know how to install or customize a module anyway. They take the vanilla pre-packaged modules.
So, in the spirit of open-source, let us say that we agree to disagree
However, this is not just Moodle development that we're talking about.
We also need a tracker that *any* Moodle site can use for tracking things (students etc). It needs to be well integrated, for all the databases we support, with completely transparent authentication etc, and it needs to be easy to use (not JUST for developers and software projects).
From my point of view, we can get both problems solved at very little cost via this project. The programmer I chose for this project was going to build a new tracker *anyway* for a project at their University.
Despite our ongoing problems with Wiki, Chat, Questionnaire and Blog (all existing projects that we ended up having to almost completely rewrite) I'm strangely not adverse to us considering starting with an existing project and modifying it a lot, but I couldn't find one that was suitable. PHPBT and Mantis were the two candidates that came even close.
If you have a better plan or a lot of free time let me know, now is the time to volunteer! No-one was volunteering before and I'm just trying to get things done here.
Apologies if my message came over like that. It was not meant to.
And them Gallery changed their integration API in an .x(!!!) release and module doesn't work with the lastest Gallery version and it's going to be a chore to fix.
Another perhaps illustrative example might be Mike Churchward's ongoing heroic effort to integrate PHPESP, which resulted in re-writing most of it, anyway.
Gallery2 stil does offer a whole lot (Gallery remote, the java ftp client is particularly sweet;), but I'm not sure it's often better to integrate with another fast moving project with it's own unique set of priorities than it is to write something from scratch.
I guess it depends how much integration is required. A tracker that integrated the Moodle features Martin described might be also be useful for course designers, and even perhaps an easy way for students to ask questions about particular bits of the course and for the instructor to track answers.
PS, Tim I share you deep and ongoing loathing for the current bug-tracker.