Tento příspěvek ve fóru byl odstraněn
Počet odpovědí: 52From my point of view and from what I have learnt from messages posted in various forums by others, the underlying problem would be the speed of development in Moodle. Roughly since 1.5 there has been little consolidation of versions before new versions were released. As a result a significant part of the community still uses Moodle 1.5, which works pretty well and the rest is spread out over versions 1.6 thru 1.9 (All of which seem to have major issues, which does not encourage the 1.5 users to upgrade.) When Moodle arrives at 2.0 the user based will be stretched even further and there will be even fewer adopters and testers, while the Moodle developers focusing on 2.0 will have little time to work on debugging and improving versions 1.6 thru 1.9. Educational organisations are often not so flexible and having one or more upgrades every year disturbs staff and creates a (false) impression of the program not being reliable.
What the userbase could use is a long breather during which many organisations can catch up and adopt (thoroughly debugged) recent versions. (The Moodle bugathon is a good initiative in that direction.) Once we have a significant number of 1.9 users we will have plenty of testers for 2.0.
My five (Euro)cents,
Paul.
Joan
Tento příspěvek ve fóru byl odstraněn
Large universities which have not a large staff devoted to Moodle, walk at an elephant ( large tortoise ) pace...
[This is definitely the case with us. We have not got any staff members who are full time on moodle and everything that goes with it. If something breaks, we may or may not be able to fix it short of a rollback! We depend on core being stable and bug free, so we usually stay behind the latest release. It is definitely a tough problem to solve!]
and
They need not "with some confidence" but a TOTAL confidence for all parts of Moodle that can be used to evaluate or grade the students (i.e quiz). This is a legal obligation.
This is absolutely the case, and I don't believe I have ever seen it articulated it quite this way before. Well said, Pierre!
atw
They need not "with some confidence" but a TOTAL confidence for all parts of Moodle that can be used to evaluate or grade the students
While this sounds reasonable, I wonder if you'd claim the same if you substitute 'Moodle' with any other product name, esp. a commercial closed one. For example, one that has reached the end of life and won't be supported any more.
Anyway, this is free software, and there isn't a vendor forcing you to upgrade to a newer version If 1.6.x is good enough for you and don't mind living with the known bugs (at least they are known
), that's fine
Saludos. Iñaki.
Tento příspěvek ve fóru byl odstraněn
Disclaimer: English is not my native language, so sometimes I can't accurately express what I want to say.
When I say this is free software, I don't mean it's 'gratis' (no cost) but 'libre' (as in free speech). That is what makes it possible for many different people with many different needs to use the software in very different scenarios.
What's an important feature for some peoples (quizes, in your example) is completely irrelevant to others (our university doesn't use them at all). Take for example the roles feature. This is clearly directed at big institutions. But roles have come with a bag of other 'side-effects'. More complex administration, slower code (partly due to a non-optimal coding, partly simply because the system has to do more things than before), etc. Some people see roles as a step back in many respects.
So while 'large institutions' are a big target, they are not the only target. And even those large institutions have varying needs, with different priorities. So going back to my initial assertion: this is free (as in speech) software; you can modify it yourself to fill your needs if the standard distribution doesn't fit your needs and the developers are more interested in other things.
Saludos. Iñaki.
Tento příspěvek ve fóru byl odstraněn
I see your point, but I'm not really sure you see my answer to your original questions:
The increasing necessary knowledge to be able to create good and stable Moodle code is a problem The testing of new code is a problem
If you need qualified people to develop and test new code, there is only one possible solution: get those people.
If good, mature, stable code is a must for big institutions, then those institutions will have to put the ressources to achive that goal. The way they can do it may vary:
- You can pay Moodle HQ to develop and test those features that are critical to you,
- You can pay a Moodle partner to do it,
- You can hire reputed, qualified professionals to do it,
- You can have staff in-house to do it,
But someone will need to 'pay' for it. And that's usually the one who's asking for certain feature. You can pay money and get it developed/fixed, or you can pay 'time' by waiting until someone decides to develop/fix it.
So to answer your last question:
do we have the right mechanism to do it?
I'd say we do have it.
Saludos. Iñaki.
Tento příspěvek ve fóru byl odstraněn
The developers code-review each other's code at the prototype and pre-release phases.
This does require a sufficient budget, for a large development (like Flexpage) 2-3 FTE for developers, 2 FTE for test/document, and an experienced project manager is essential.
Getting the budget necessary to Moodle.com for the core code, testing, and documentation is the job of the partners, and folks with large implementations can help out a great deal in this by commissioning Moodle.com (as OU does a good bit of) or by working with a partner. I do think that to develop production ready, tested, code you need a professional development team, and such a team needs a budget to continue producing good code.
I know it's hard to make this argument at public institutions--at HSU we developed the 1.5 gradebook with a shockingly small budget (compared to what Sakai spent, or what I'm sure Blackboard spent), for instance. It was never as well tested or designed as it should have been - but there was no real budget.
Anyway, in my experience it takes 3-6 months for an experienced programmer to start writing production ready code for Moodle, so it is essential to be able to support these individuals and to be able to keep them working on Moodle once they've learned it. We're working with some large clients to try and build internship programs to bring student programmers and support staff in early. Some of the CS faculty I used to work with at HSU and some Kevin Kelly works with at SFSU have started building Moodle modules in the CS classes--likely few of these will be production quality, but we can help students learn some of the API and identify whether Moodle is a project they like working on.
Long run, I think it would be very interesting to look at the application exchange model of Salesforce and Facebook--where developers can build and implement new modules via a web interface, without touching the core source code--and these new modules exist in a DMZ so code errors can't take down the system. (We're building an integration with Salesforce, and I've been quite impressed with the ease at which a new module can be loaded in.)
As partners take on larger projects and build revenue streams, I think the partnership program is starting to provide a decent budget back to Moodle.com for development, and hopefully this will increasing in the coming years. I've looked at quite a few open source project business models, and the Moodle partner program is one of the best I've seen for being able to provide open source code while keeping the core team appropriately funded. We'll see
I fully agree with you.
Many institution did achieved in that conclusion that open-source means free to get (that's pragmatically true) and free too use. I have a quite global (but not exhaustive) oversight of the way schools and universities in France do consider the cost of managing and driving their e-Learning facilities : null.
There is a huge issue in France to make thoses institution accept they would have to pay for custom developments, although they do accept without any doubt the cost of changing a light bulb or reparing sanitaries.
The exact cost of a real Moodle administrator in a large university or graduate schools (I deal with institutions that are not so big : 600 to 1000 students) is never identified. The role is generally assumed by a good-willing teacher, that is fed up with administrative inertia, or lack of operational support.
The fact is that trying to create a "professional" agency making value with Moodle development is a real Challenge here. As we know that development of features do follow the exact rules you told...
Maybe the increasing complexity of Moodle code should "protect" people whi have developped high knowledge, and let a real economical path open for them...
The result might be : less contributors but better code... That my opinion.
I whole-heartedly agree with everything you said Valery,
I work at a third-level institution in Ireland, where my job description has developed over the years to include:
Full-time I.T. Trainer,
Database Analyst/Programmer,
Integration & Test Specialist,
Web Master,
Moodle Administrator,
Moodle Developer ,
& last but not least, general Dog's Body to do any other thing that I quite mistakenly left off the above list... and i'm sure, like some teachers in France my goodwill has just about been exhausted!
Like your situation, budgets are virtually nil, but expectations are through the roof, and everything is wanted yesterday!
The result might be : less contributors but better code...
That's a suboptimal result. We can do better than that - more contributors mean that we need is more reviewers and testers.
And that is what Tim Hunt wants AFAICT. As a maintainer, when someone submits code, the questions are:
- How long has this code been running in production?
- How many different Moodle installs have been using it succesfully?
- Has it had a good shakedown of bugs?
- Is it popular with users?
- How many eyes have read and debugged the code?
- Who wrote it? Will that person help maintain it?
- What about long term maintenance?
All of that can be achieved by getting module authors in /contrib and encouraging users to try their modules and report bugs in the forums or tracker. That way, it's easy to see what code is popular, has active maintainership and how it is maturing.
That's what the linux kernel team does, and we should do more of it. For example, even though I have CVS access, I often flesh out my code in the forums, looking for testers and reviewers. Along the way, I end up with a few co-maintainers that have tested/read/reviewed the code with me. Like here http://moodle.org/mod/forum/discuss.php?d=80104
This model scales extremely well -- there are some amazing stats of the thousand of developers contributing to the linux kernel through this model.
That's what the linux kernel team does, and we should do more of it.
Agreed, and we also have an advantage over the kernel model as contrib plugins aren't suffering similar fate to contrib kernel developments (being relatively difficult to use).
Moodle plug-ins are by their nature easy to plug in! Some modules are better in contrib, not just in terms of code maintenance, but uncluttering the core user interface, improving the documentation and support burdens for fringe tasks. We have the modular plug-in points available in moodle, the repository, the tracker and the forums all available to contrib. Contrib authors need not feel like second-class citizens. ;)
Essentially, I envision it being a matter of creating a CONTRIB issue in the tracker to create a new plugin or patch and uploading the code in the tracker. From there I will be able to create a directory in CVS, drop the code in, grant the appropriate write access to the director, and create a component in the tracker so that feature requests, bugs, etc. can all be handled through the tracker.
My hope is that by having the code all in CVS that developers will be able to more easily evaluate the code and that by having the tracker those doing the development will have access to that resource for getting feedback from users of the code.
Feel free to let me know if there is anything I can do to be supportive of 3rd party code or if you (or anyone) has questions about how to contribute. Peace - Anthony
Tento příspěvek ve fóru byl odstraněn
Have you got access to the scripts that create the .zip files automagically from the plugins/modules in contrib? (I'm fairly sure one exists
I'd be keen on extending it to support other SCM repos -- you can probably imagine of what kind
"Organizing 3rd-party ..."
I apply for giving you a hand in that huge task if you need some, Anthony.
Indeed, as everyone else says it sounds perfect, thanks!
I'm really not a fan of the zip file after zip file in one long thread approach to third party module releases; its hard to see the history of the code, what things have been fixed and attempt to find out if there are any issues I should be aware of as an administrator.
Hopefully if more third-party authors get more familiar with the tracker we'll also start to get some more good quality bug reports for moodle core too!
That's a key point, obviously.
We work in that kind of application using so powerful languages (Php is such a powerful language; like Perl) that a skilled developper can develop very fast a complex application, generating in a couple of hours tens of uses cases. There is no way for the developper to test them all in a reasonable time. Making real Unit tests for all features pushes publishing date far away.
The collaborative model turns also sometimes to concurrent initiatives, some kind of race where "making it faster" seems being a guarantee that you'll get some attention from the community.
The more the community large is, stronger is this kind of concurrence, although our contributive side dominates, as we learned from the Moodle culture to take major benefits of overal cooperation. This is natural, all concerned people need making sense to their work, and there may be sometimes frustrations from getting overriden by a weaker implementation.
We know what the best process is to avoid such issues : communicate our job and individual workplan into the forum. It works fine, and you may have interesting advising or to start the job or not.
Martin is right about testing strategy, although we should better the testing phase.
Some part of the problem is that there is not enough (formal) information about the state of a published plugin, (i.e. not qualified records). You have to install, open the plugin and dig here and there to check what is the real implementation level.
I started a little crusade at my level getting valuable old modules being renewed, finished and setup to a full API implementation. Testers can be found, it needs just a bit of time.
We need two kinds of ratings for Modules and Plugins: community ratings, and moderator ratings.
1. Community Ratings: let users rate a module by stars from 1-5, and offer comments. Versiontracker has an excellent system as a model. Then let readers rate the ratings, by offering yes/no buttons to the question, "Was this comment helpful?"
2. Moderator Ratings: let an experienced developer(s) serve as moderator(s) of the Module/plugin database and offer other ratings according to quality standards as Martin has listed--code consistancy, documentation, shakedown of bugs, maintenance record, accessibility compliance.
In addition, some standard information listings will help administrators choose third party code better--time in production, popularity with users (number of downloads, number of reviews), roadmap, speed of bug resolution.
I have done my share of stupid stuff and would probably continue to do so without the likes of Petr Skoda looking over my shoulder (in the nicest possible way). I am aware of the responsibility that having CVS commit access to Moodle give me and if I have learned anything is that Moodle Development *is* a team sport. You have to rely on anybody else you can get to engage with you to sanity check what may seem to you to be even the smallest changes.
The pluggable architecture and the use of contrib wherever possible is, I think, a great thing. It actually means that you have to sell your plugin really hard to even stand a chance of getting into core Moodle. That's a good thing in the end as it places an implicit quality filter in the way of dodgy code and less than useful additions.
Michael, I think this is right on the money! It's interesting to note that recently Facebook has created an environment that will support application exchange in this manner. There could be some fun and interesting possibilities there. And very cool on the Salesforce.com integration!
This does come up and I've been looking at it closely along with several other projects we will integrate Moodle with in 2008.We will soon announce Moodle DevCon I to take place next May in Arizona, in cooperation with the Sloan-C Symposium event at Carefree. I think it would be great to have a track on this issue lead by Moodle partners, focusing on business development and connection with supporting technologies. And, we should find out if Martin's new haircut is at a crossroads.
Yes - and I am sure lots of people do that because Moodle is very accessible (not just because it's written in php). I have a minor modification to weblib.php around line 2200. I made a note of the change of course - but 2 years down the road with lots of such tweaks upgrading to new versions becomes very problematic.
If you are modifying the code, you should be using a source control management system (cvs, subversion, git, etc.). This makes upgrading to newer versions easier (easier, but not a breeze .
Anyway, unless it's just a minor tweak (where upgrading is really simple), I try to push any major 'surgery' back into the standard Moodle core, so a) I don't need to do it again in every later version and b) it's available to other people too.
One strategy that has proven to be successful is discussing the 'surgery' with the developers before doing any code at all, instead of trying to push finished code that may or may not fit the developers expectations in that area.
But I guess I'm going off-topic here...
Saludos. Iñaki.
I agree with Tim drawing up some rules - though they are probably flexible
What to do? Encourage people in the forums to test your code and report success/problems. All code takes a bit of time to mature, try your best to make that happen before it gets into an official release. The good news is that the users that grab code from contrib are more enthusiastic and more knowledgeable - you'll get good quality bug reports from them
Tento příspěvek ve fóru byl odstraněn
The problems you mention are quite common -- every programmer faces it when developing a new feature in a popular project. In fact, Dan is right: compared with other projects it is trivial to install modules/plugins in moodle. Barriers of entry are low.
Getting the early adopters to try it out is the winning strategy. They are just a few, but it's that self-selected group thst you need. Perhaps it's time for a bit of marketing, people often do a "mini-release" every couple of weeks and use it as an excuse to post in the appropriate forum mentioning what's new & improved...
If early adopters don't test it, perhaps it's not that interesting (overlaps with something else? maybe it isn't clear what it does?), and therefore it's good that it stays in contrib. It is all very natural... in other words, it will be the end-users saying "this module is great, has no bugs, and usable in all these situations; get it in the official release to save me the hassle of installing it separately" that will get you there.
Tento příspěvek ve fóru byl odstraněn
Re: Is Moodle development at a crossroad?
There has always been great pressure for new features from the community. Many people want to add "just one more thing" and there's thousands of these. Hundreds more want to have the flexibility to change things like permissions (I think a lot of people have forgotten how many little one-line code hacks were around in these forums before Roles, to implement little permissions changes that people wanted - all of these are now a tweak in the Roles GUI).
It would have been easy to just focus on the feature requests only and hack them in quickly using the Moodle 1.5 API (for example) to keep the development learning curve lower for casual programmers however, we would right now be drowning in a sea of thousands of inconsistent features that were completely inflexible and hard to maintain (like some of the early modules that got into core, like Wiki and Workshop). Moodle would have been basically dead under its own weight in two years, I'm totally sure.
Most of the major changes in the past year or two have been core refactorings (Roles/Permissions, global Unicode support, XMLDB, Moodleforms, XHTML Strict, Gradebook, Unit tests) chosen explicitly and intentionally and with much thought to improve how Moodle operates as a system, to give it strength from the inside and thus longevity as a platform.
Yes, it's true that there is more Moodle API to learn, and the learning curve for some types of plugins is greater, but I think the payoff for everyone is a Moodle platform that is more stable, more accessible, and more flexible. Many of the issues people have with APIs are just a matter of good examples and documentation. (Try writing applications for Windows or Mac OS X and see how many APIs you need to obey!)
The Bugathon reflects the fact that many people have a perception of recent versions as being more buggy. In some areas that's true, in others the problem is more that user interfaces, documentation and 3rd-party modules didn't really keep up with the core code.
As we grow, and people's stakes in Moodle increase, I think we need to always increase our standard of quality. A lot has been happening to improve processes and management of this project (tracker, documentation, contrib etc) and this will continue. In the end though, we do need people learning to engage with each other in a structured way. This is another aim of the Bugathon.
I don't see us at a crossroads at all - we're proceeding along the same basic road I've been mapping for years (derived from community requests and activity).
If we switch from a driving metaphor to a mountain climbing metaphor, I see us right now camping half-way up the mountain, pausing to consolidate and regather strength from yesterdays climb and preparing to climb again tomorrow.
Tento příspěvek ve fóru byl odstraněn
there is no such forum in the list
this is the forum -- most/all the key devs have posted in this thread. We do need to use it more...
Tento příspěvek ve fóru byl odstraněn
Re: Is Moodle development at a crossroad?
For many of these the wiki format fits better than a regular forum.
Perhaps a major problem is documentation for developers. Some parts of Moodle are quite well-documented but the documentation isn't all in one place and might not all refer to the same versions. Really there should be a tutorial for each plug-in type, and this should be synchronized with versions i.e. it should be part of the code base and a new version shouldn't be released until the tutorials have been updated as necessary. Unfortunately, Moodle has quite a lot of plug-in types.
If anyone wants to contribute significantly to improve the project it would be nice if they contributed documentation, not new development. (Yeah, I don't think I'll be convincing my employer to do this any time soon
One other important aspect - so that we don't really have to write 20 completely different tutorials - is to make our plug-ins as similar as possible, at least where this doesn't detract from the possibility to make improvements. Moodle is quite good at this (for example, if you want database tables for your course format, the install.xml and other files are exactly the same as for a module) but could be better. (Actually I'm going to look at one possible minor issue of this type today hopefully.)
I agree that forms (especially) are quite difficult to do, but they're also quite important in terms of ensuring a degree of similarity. With a tutorial, they'd not be so bad (and there actually is documentation for forms - which is great by moodle standards, and sort of okay by general standards).
As for the issue of versions and rushing etc - 1.9 is a fairly evolutionary version and more a matter of improvements and reliability than a dramatic feature update. The only massive new feature is gradebook, which has been quite thoroughly tested (we are going to use it for assessment so it had better be) and looks to me [I wasn't involved at all and don't know the detail] like a really good bit of Moodle.
I think if you're starting Moodle next spring, 1.9 would be a good bet for a solid version. If you have to start right now, 1.8 would be an OK choice. Certainly now isn't a good time to start with 1.6 because that guarantees a big change later when you are ready to upgrade. (And if you really want a 100% reliability and security guarantee? Moodle 1.6 doesn't have it, nor any other version ever will, nor any other program.)
--sam
is a Key about a long run.
I used to provide "little one-line code hacks" before roles and I am not so sure it was a bad thing.
Where is the top of this mountain? Are folks climbing it soley because it is there?
To what small, even miniscule extent, is the mountain made of bank notes?Were roles created soley due to popular demand or because they where paid for? Is the mound of bank notes so small, too small to hear?
shh.
Tim
Moodle.com won't take on work unless they decide it will fit with core Moodle. I can tell you for a fact that they have rejected at least one Open University outsourcing proposal for exactly that reason, despite the fact that yes, it would have involved money. (And the roles system doesn't work quite the way we originally wrote the spec, for that matter.)
So if you think whoever has the biggest chequebook gets to control Moodle development, you're completely wrong.
I don't really understand what people think the problem is for developers, due to roles - they can be a little complicated in certain aspects but that's what the library functions are for. Generally for a module developer it's no big deal. Adding capabilities is really easy. Testing capabilities is really easy. Most of the time, that's all you need to do.
And the role system works in a fairly similar manner to role systems in every other product that does anything like Moodle... (arbitrary list of roles, each contains a bunch of permissions, you can allocate a role to a user in a particular context, the software makes decisions by evaluating the permission for a user in a context)
--sam
PS I agree the details of the role system can be complex and confusing, when using role overrides or multiple roles. But that really shouldn't affect developers of anything much bar the role system...
but it was also done because it was widely recognised that Moodle's existing limited number of fixed and arbitrary roles were inadequate for large-scale use.
And even for small-scale use !
We have hundreds of [primary/secondary] schools who had to face the barrier of moving to the roles system and at the time of the roles transition I wasn't convinced of the need for it for those users.
However as time has gone by, our school users have proved me wrong. Questions frequently come up about giving some teachers the ability to change passwords, or giving limited parental access to moodle, or allowing student 'champions' to monitor forums.
Moving to this more complex system has been a uphill challenge for users [1], however it gives moodle so much more value as a product! As Martin was reffering to, the examples I give above would all need to be coded as custom hacks and settings applied in an unstainable way. This wouldn't make moodle any more developer friendly and would probably eventually have resulted in the same performance problems as MartinL just battled through, but not able to be solved in a central way.
Millions of users want to do millions of different things with Moodle and I think the biggest challenge we face is allowing all these inovative uses of moodle whilst ensuring it is usable and not plagued by millions of settings to facilitate this flexibility!
[1] I would argue that most of the user-based barriers have been a side effect of pre-roles assumptions in moodle [for example the definition of a student enrolled in a course or a teacher of a course is a bit more complex ].
Thank you for making that clear.
> So if you think whoever has the biggest chequebook gets to control Moodle development, you're completely wrong.
I think it only realistic, and reasonable that the size of ones checkbook should have some influence upon the direction of Moodle development. But above all, I think that the financial considerations are worth mentioning.
Tim
Re: Is Moodle development at a crossroad?
I'm following this discussion since the beginning and I must admit that it's being really interesting, plagued of perfect comments here and there.
Anyway, I think I'm missing something important. Er... uhm... can anybody explain me what the hell is a "crossroad" ?
Ciao
Re: Is Moodle development at a crossroad?
Es español diriamos que es una encrucijada
Saludos. Iñaki.
Re: Is Moodle development at a crossroad?
Re: Is Moodle development at a crossroad?
(now that I know the meaning it seems pretty obvious)
Anyway, following the simile... one crossroad only exists if there are roads around it, so if we are in a crossroad, can anybody clarify/comment/detail which are the possible roads?
In other words, is there a correct road? Or what should we (all) do to make the road(s) better for all the vehicles using it?
Ciao