Hey everyone-
I was assigned a presentation for graduate class about any open-source project and I chose Moodle. It seems like a well developed project that has, and will continue to, provide a valuable tool to educational institutions looking for an alternative to commercial products which makes it an interesting topic to delve into. Questions dealing with source management, project participants, history, etc are easily answered on the website. But some of the more interesting questions (my class is focused on the development process of open-source projects) are only answered by those that are involved in the development process though and I was hoping someone wouldn't mind helping me out.
For instance, how do developers communicate? Many open-source communities have IRC available, but I didn't see that here. Are these forums and email exchanges the main method of communication?
How are conflicts within the project resolved, ie, if two developers have different ideas about how to implement a feature, who decides which to go with? Just from reading through the website and related info, I would guess that the final decision falls on Martin, is that fairly accurate?
What's the best way to get involved in the project? There are many areas layed out that always need help, but once you develop a theme, documentation, or other code, how does a new guy go about getting it approved/reviewed or whatever the appropriate thing is?
Last but not least, what drives releases? Meaning, are there dates that you all are shooting to realease at? Are there certain features you tag for completion and when they are complete you release a new version? What's the drive for that?
Any help with this would be hugely appreciated. I'll be checking back here as much as possible (report is due sooner than later of course), but if you could drop me an email at zollinhm AT gmail DOT com if you post a response here or just include the response in the email, that'd be great too.
Thanks again,
Matt
I cant answer your questions, but I thought if I were doing this, I'd go with something like mambo/joomla, or even xoops. Cos there're more "happenings" there that you can investigate and write on. Moodle seems to me to be a rather peaceful community with things running really smoothly - maybe it's because people here are also educators 
...
I appreciate the reply. Yeah this seems to be a pretty peaceful community, which another reason I'm interested in getting involved. I don't have an urgent need for drama 
.
If anyone has any thoughts about any of the questions, not necessarily all of them that would be helpful too.
Thanks,
Matt
If anyone has any thoughts about any of the questions, not necessarily all of them that would be helpful too.
Thanks,
Matt
Matt, you're right, this is a pretty low-drama community. Debian OTOH is a lot more "fun" on the community dynamics, Biella Coleman has done a lot of research on how FOSS groups deal with conflict -- really recommended: http://www.healthhacker.org/biella/
In any case, yes, we all trust MartinD, so he calls the shots. Except that in practice it almost never ever happens. There are other more indirect ways of dealing with conflict.
In any case, yes, we all trust MartinD, so he calls the shots. Except that in practice it almost never ever happens. There are other more indirect ways of dealing with conflict.
Hi Matt, and welcome to Moodle! 
Here's a not-so-short set of answers to your questions to get you started until more answers arrive.
Communication: When throwing ideas around, the General Developer Forum has served well in the past. Discussing how something should be designed or implemented can benefit from a multitude of opinions, and that is the place to get them. For two- or three- person chatting (usually on a quite specific issue), we use email if it's not urgent or needs time (e.g. you want other people to review a patch) and Skype if it's something immediate. Finally, there is also the Security Center where security-related discussion goes on every so often (this is like email, for me at least, but with the advantage of being more closely monitored by everyone).
Conflicts: If there's something that can't be solved by discussion then it's Martin's call. This happens rarely, if ever, though. Sometimes it's also a case of who invests the time to do something; obviously the details of that will reflect the ideas and habits of the person who did it.
Releases: Mainly time-driven, although there have been some big release date slips in the past (1.5 anyone?). Usually there's a set of features planned for the next release and a target date. The planned features most of the time are complete before the target date, so it's a question of what unplanned features will get into the release. At some point Martin declares the code base frozen and from that point on there's only bugfixes until Moodle is good enough for release.
Getting involved: The simplest way is to start small. Post patches in the bug tracker, post patches when you have an issue to discuss (both in the tracker and the forums). If you want to develop something a little bigger, you can try a Block. Generally, the more good karma you have built up, the easier it is for others to accept large chunks of work "as is". In any case though, the number one pointer I can give is: pick something people want and work on it. This will get you:
Cheers!
Here's a not-so-short set of answers to your questions to get you started until more answers arrive.
Communication: When throwing ideas around, the General Developer Forum has served well in the past. Discussing how something should be designed or implemented can benefit from a multitude of opinions, and that is the place to get them. For two- or three- person chatting (usually on a quite specific issue), we use email if it's not urgent or needs time (e.g. you want other people to review a patch) and Skype if it's something immediate. Finally, there is also the Security Center where security-related discussion goes on every so often (this is like email, for me at least, but with the advantage of being more closely monitored by everyone).
Conflicts: If there's something that can't be solved by discussion then it's Martin's call. This happens rarely, if ever, though. Sometimes it's also a case of who invests the time to do something; obviously the details of that will reflect the ideas and habits of the person who did it.
Releases: Mainly time-driven, although there have been some big release date slips in the past (1.5 anyone?). Usually there's a set of features planned for the next release and a target date. The planned features most of the time are complete before the target date, so it's a question of what unplanned features will get into the release. At some point Martin declares the code base frozen and from that point on there's only bugfixes until Moodle is good enough for release.
Getting involved: The simplest way is to start small. Post patches in the bug tracker, post patches when you have an issue to discuss (both in the tracker and the forums). If you want to develop something a little bigger, you can try a Block. Generally, the more good karma you have built up, the easier it is for others to accept large chunks of work "as is". In any case though, the number one pointer I can give is: pick something people want and work on it. This will get you:
- Lots of volunteer testers
- Better peer review (with time being a limited resource, developers will review what's most likely to go into Moodle; quite often, that means what the users want most)
- Invaluable experience with the development procedure (e.g. acting on feedback; this will prepare you for when you have some code to support and a user base large enough that expects stability)
- Increased chance for your code to be housed in Moodle's CVS tree (/contrib/ initially, and if it's something really useful and good the main distro)
Cheers!
Jon Papaioannou wrote:
Getting involved: The simplest way is to start small. Post patches in the bug tracker,
Nice it theory. It didn't work for me: bug 4363
Tim.
Getting involved: The simplest way is to start small. Post patches in the bug tracker,
Nice it theory. It didn't work for me: bug 4363
Tim.
Tim, please don't feel sad - you're very welcome in the Moodle community However, please understand that we have a problem right now, as Martin explains in the Moodle Community Newsletter:
However, please understand that we have a problem right now, as Martin explains in the Moodle Community Newsletter:"... weve grown so large recently that its impossible to keep up with everything anymore and a lot of voices and code gets lost in the flood. Better than no activity, I suppose, but not good! Many of my plans for the future involve better channelling and organising this community energy to help power Moodle development into the future."Please stay around - no doubt your skills will be appreciated in the future
Tim-You rated your bug as minor and priority 1. It doesn't appear that anyone has rejected it, so in in theory it could still be fixed using your patch. And especially since 1.6 devis still not standard, it is likely that a low priority item like this may not get incorporated until the developers deal with more serious and difficult issues.
Also the patch deals with an authentication plugin, so it may be a good idea to find out who maintains that plugin and either assign the bug to them (not sure if non developers can assign bugs in the tracker) or at least send them an email saying 'Hey, I posed a patch for you'.
Bugs get assigned by default to 'dougiamas' in the bug tracker if there isn't a maintainer assigned to the component the bug was marked as... and there are probably five million bugs assigned to Martin that haven't been reassigned.
This patch should be marked as Component: Authentication. What would be really good in the bug tracker would be dependent drop down menus, so when you pick 'Authentication' you get a list of the different plugins. However, we don't have that at the moment, so you could just choose Authentication, and maybe put 'cas authentication plugin' somewhere obvious in the bug report, like the title.
A good way to find out who is the maintainer of an area (if not documented already in the README) is to check the CVS commits. Example:
http://cvs.sourceforge.net/viewcvs.py/moodle/moodle/auth/cas/
From that you can see that there are two committers, phoenixfr and skodak. I know that skodak has probably been there cleaning up, rather than doing development, and you can tell that from the last commit messages (code cleanup - see SC#129), so it would safe to say that phoenixfr would be the person to bug. Then you go to http://sourceforge.net/users/phoenixfr and there's the email address.
Granted this is a rather round about way to get someone to notice your patch, which is bad. It would be really good if the component screen was expanded and more maintainers assigned to certain pieces. This way, your cas auth patch could be assigned to the right person.. unfortunately, it isn't this way at the moment, so the best thing would be to either post on the authentication forums, or email the maintainer.
I hope that helps. I know it's frustrating
Edit: Another suggestion - for the bug tracker (at least for the developers) we should all perhaps use our sf.net usernames so that people can make the mental leap from cvs committers to bug tracker people.
Bugs get assigned by default to 'dougiamas' in the bug tracker if there isn't a maintainer assigned to the component the bug was marked as... and there are probably five million bugs assigned to Martin that haven't been reassigned.
This patch should be marked as Component: Authentication. What would be really good in the bug tracker would be dependent drop down menus, so when you pick 'Authentication' you get a list of the different plugins. However, we don't have that at the moment, so you could just choose Authentication, and maybe put 'cas authentication plugin' somewhere obvious in the bug report, like the title.
A good way to find out who is the maintainer of an area (if not documented already in the README) is to check the CVS commits. Example:
http://cvs.sourceforge.net/viewcvs.py/moodle/moodle/auth/cas/
From that you can see that there are two committers, phoenixfr and skodak. I know that skodak has probably been there cleaning up, rather than doing development, and you can tell that from the last commit messages (code cleanup - see SC#129), so it would safe to say that phoenixfr would be the person to bug. Then you go to http://sourceforge.net/users/phoenixfr and there's the email address.
Granted this is a rather round about way to get someone to notice your patch, which is bad. It would be really good if the component screen was expanded and more maintainers assigned to certain pieces. This way, your cas auth patch could be assigned to the right person.. unfortunately, it isn't this way at the moment, so the best thing would be to either post on the authentication forums, or email the maintainer.
I hope that helps. I know it's frustrating
Edit: Another suggestion - for the bug tracker (at least for the developers) we should all perhaps use our sf.net usernames so that people can make the mental leap from cvs committers to bug tracker people.
There was a long thread last March exploring some of the links between the open source development process and the social constructionist pedagogy underpinning Moodle. It might provide some insights if you have the patience to read through it. See http://moodle.org/mod/forum/discuss.php?d=20801
Wow, thanks Jon and Miles! Jon those answers were perfect. Honestly I was hoping for an answer that clearly written but I wasn't expecting it at all. Miles: I got through about half of the social constructivism discussion which is pretty interesting (but you are right, quite long). I'll have to finish it another day.
Anyway, thanks a bunch.
Anyway, thanks a bunch.