Quantcast
Channel: Recent posts across whole site
Viewing all articles
Browse latest Browse all 49199

drupal.org projects as Organic Groups

$
0
0

(Note: this was going to start life as a comment over at John's vision for d.o project pages, but I don't want to hijack that thread with a whole new train of thought...)

Summary: Each project on drupal.org should be an Organic Group.

By "organic group", I mean we should use the Organic Groups module (aka "OG"), which is what powers all of the groups here on groups.d.o. So, the sorts of things you can do on group pages here, you'd be able to do on project pages, wherever project pages end up living after the redesign (code.d.o, download.d.o, projects.d.o, whatever).

Why this would be cool (in no particular order):

  • Projects should have their own "handbooks", linked directly off the project page. Basically, there could be a "Documentation" tab on each project.

  • I think it'd be slick/easy to create a little "FAQ" node type for projects, and have an autogenerated view of FAQ nodes for each project. Again, maybe there should just be a default "FAQ" tab.

  • The Aegir group page is a good model for what project nodes could become, showing off some of the power of having an OG dedicated to your project.

  • OG would handle all sorts of subscription/notification functionality so "we" don't have to. ;)

  • Projects-as-OG would also solve the project "blog" problem. I'd much rather people were putting these announcements or discussions directly on d.o than providing a bunch of glue to make it easier for project nodes to point off-site. The more this stuff lives on d.o itself, the better (e.g. for unified search).

  • og_panels would provide a lot of nice power/flexibility for project maintainers to customize their projects if they wanted. I spoke to sdboyer a while ago about some code he was working on that would make it possible to "lock" a set of panes in all the project panels, while still giving maintainers the ability to customize parts of it, add new tabs, whatever. So, the basic UI of the projects could be consistent, and if you didn't spend any time on it at all, the default UI would be good, but maintainers that wanted to pour extra value into their project homepages could do so, just like interested group maintainers can do on this site.

  • If users subscribed to the OGs for the projects they used, all the cool stuff we're talking about over at Flag for "I've used this module"? would basically be possible without an additional flag.

  • Since there are different levels of membership in a group, OG could also help solve issues like this: #69556: move "cvs access" tab into project, make it generic, and add issue maintainers, #253825: Allow project co-maintainers to assign issues to each other, etc. Basically, instead of hard-coding any of this directly into CVS, we could just let the different levels of membership in an OG determine project-specific "roles" you play and corresponding permissions you should have. It'd be pretty trivial to give a trusted collaborator permission to work on your project's documentation and help maintain the issue queue, without giving them direct revision control access to your code.

I'm pretty sure I wrote up some similar thoughts somewhere else at some point, but I don't remember where that is. ;) So, I wanted to start a new thread about this specifically in light of the redesign...


Viewing all articles
Browse latest Browse all 49199

Trending Articles