Moodle Community Sites

Great plan! Moving away from 'per-developer' areas is a good move.

A few comments:

• Might be good to not use 2nd level subdirs for the categories to ensure top-level visibility, and for clarity. The main case is the plugins or submodules to modules. The current structure is confusing in this case when you are looking at the mod/ directory:

/mod/foo - contrib module foo
/mod/assignment/type/blah - contrib type blah for the official mod/assignment

so I'd propose
/mod/foo - contrib module foo
/mod-assignment-type/blah - contrib type blah

and similarly

• admin-reports
• auth-plugins
• course-format
• etc

then actual module/plugin is on the 2nd level subdir: /contrib/$type/$thethingitself

• artena_sms can be nuked

• Should we keep the 'devtools' subdir? Don't nuke it just yet - but I can move it elsewhere (like http://git.catalyst.net.nz/gitweb )

Yeah - I think top level visibility is a good idea too.

Hmm, it has advantages in you'll see 20 directories laid out, but I think overall I disagree with this, because:

1) it's not consistent naming, and developers WILL make mistakes and have misunderstandings (look at the current hodge-podge!) They'll make them anyway but it's harder when the structure so obviously mirrors Moodle.

2) auto-linking from moodle.org posts, docs etc to CVS entries is made more complicated

3) it's not meant to be the primary browsing interface for users. There's Moodle modules and Moodle docs, and there could also be an INDEX.HTML with a pretty listing if that was required...

MartinD - a couple comments about the layout I suggest:

1) it's not consistent naming,

Agreed, it's not consistent with the moodle code, but it is consistent with the usage model of /contrib. Making it consistent with moodle code creates problems and special cases. Consider the case of an unofficial module foo that (like mod/resource) takes "type" plugins developed independently.

mod/foo is maintained by john
mod/foo/type/zee is maintained by john as part of mod/foo
mod/foo/type/bar is maintained by carl and is not really part of mod/foo but an optional component

it's impossible to tell what's what:-/ . Instead, consider

mod/foo (including type/zee)
mod-foo-types/bar

In the above scenario, also consider granting CVS rights separately to nested subdirs. I don't think that cvs can handle that, but I may be wrong.

2) auto-linking from moodle.org posts, docs etc to CVS entries is made more complicated

To auto-link to cvs entries you have to know the path anyway. It doesn't come 'naturally'. My proposed naming convention would make it a lot easier for the scripts that auto-generate the downloads for contrib code as you don't have to teach them that mod/resource is not a contrib module.

3) it's not meant to be the primary browsing interface for users.

+1 - and still keeping it as a possible browsing interface is perhaps good

Making it easier and removing special cases (having mod/resource will be confusing) helps. If it's /contrib/$type/$thing its trivial to generate packages .

Changing subject a bit – what do you think about /contrib/devtools?

Is there a desire to accomodate more than just cohesive plugins in contrib?

E.g. take something like the Activity Locking mods, these are a mix of plugins as well as mods on core components. Surely laying out the directories to mirror actual plugin locations would prevent easy inclusion of patches against core stuff, and thus discourage these sorts of extension projects from hosting their src in contrib.

Yes, good point Munckfish, those sorts of things would not go in the tree, we'd need a couple of extra directories for that sort of thing.

"patches" maybe

ML, I'm not entirely convinced. The hierarchical model is well tried and works fine in the main codebase, and I think scripts can always be made smart about packaging either way.

In your example (1), the foo-type plugins would be in two separate areas , rather than in one coherent place, which is a bit wierd. Your rational for separation is purely on author, which is something we are trying to avoid here. We want the author of mod/foo to have to use the code of mod/foo/type/bar and engage with the authors, don't we? It breeds collaboration.

One more reason, you can easily checkout the whole of mod/foo from CVS separately and include it in a main CVS checkout of the main codebase. I do this all the time.

However, if you (and others) really want the flatter structure then I'm happy to take it to a vote in Using Moodle.

I've got no problems keeping devtools where it is, cheers.

> However, if you (and others) really want the flatter structure then I'm happy to take it to a vote in Using Moodle.

I think any advantages in they layout I propose are marginal/not-so-important, so not worth the hassle also, I made things confusing writing about authors when I was thinking a bit more about mini-projects with a lead or maintainer each :-p

Thinking more about it, perhaps it makes sense to have 2 "contrib" directories [which we can easily have], one following the moodle tree structure as you propose, and another one for things that don't quite fit there, like what Munckfish mentions, and collections of bits like devtools. So keep (but prune) contrib and create "extras" or something like that following the moodle structure. In short, have both.

The ticket is here:

http://sourceforge.net/tracker/index.php?func=detail&aid=1599070&group_id=1&atid=200001

Refactoring all done, just waiting on a reload from SF.

In the meantime, all CVS access to contrib is suspended (I edited avail file)

Next up I need to fix all the downloads packaging and CVS access 8-o

Note that we are STILL waiting for sourceforge to do the final step (which would take two minutes at most).

OK, we're in business. http://moodle.cvs.sourceforge.net/moodle/contrib/

I'm restoring permissions ... please file new bugs here if you need anything done.

(whoops, didn't send this yesterday)

Note that we'll be changing the download packaging.

All directories/modules will be zipped and placed in directories matching the contrib structure, eg:

http://download.moodle.org/download.php/plugins/mod/certificate.zip

can we please have a few more fields in the modules & plugins database for the different dowload versions?

thanks!

Dan

The automatic download system doesn't seem to be working with branches. I've added the directory 'activity_tracking' to the '/contrib/patches' directory with a MOODLE_17_STABLE branch, but the link: http://download.moodle.org/download.php/patches17/activity_locking.zip doesn't work.

I have some docs in PDF format that are too large for moodle.org forums, and docs.moodle.org doesn't accept PDF uploads.
...thinking of creating contrib/docs -

To flesh the idea out more – and to give the contrib/docs directory some structure,what we can do is follow the same high-level structure as docs.moodle.org, as in: contrib/docs/$lang/Blah. So the material I have is for teachers, so I'd create contrib/docs/en/Teacher/foo.pdf

Well, we have this already: http://moodle.cvs.sourceforge.net/moodle/docs/

But I'd like to see all that moved to contrib/docs I think so it's more accessible to developers and becomes a bit more noticeable. There are no "core" docs in there, it is all contrib, so it makes sense.

+1 for the structure to mirror moodle docs