(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...
Comments
Oh yes.
This is all great. Could solve many, many of the current issues with project nodes without putting any/much additional weight on project module itself - and it's the kind of thing which is a very good reason to go with multiple sites for. Would help a lot for tracking issue queues. At various times I've tried to help out in views, panels etc. - this would make it much easier to check in what's happening.
I love the idea!
I think it's a wonderful idea! Especially if we look at how panels was introduced to improve the group pages at g.d.o, I think this would be a huge plus for projects. Module maintainers could add module-specific pages, handbooks, discussions et al.
I do wonder what the impact of this implementation would be on g.d.o itself. There currently are a lot of groups created specifically for a certain module, would those move to the drupal.org project page then?
I hope so.
One of the difficulties in finding documentation is that it is scattered. Being able to pull that documentation to one place would be "A Good Thing"(tm).
Great idea.
Could a mock up g.d.o/project/foo be created? Could such an idea just live on g.d.o or would projects.d.o be better?
Each project could have it's own forum within its group page. I assume that the project creation would become an o.g. creation instead.
How about sub-groups? Each maintainer would have a group and then each project managed by that maintainer would be a sub-group of the maintainer group. Probably not a good idea.
No sub-groups
I don't think it's valuable to have groups per maintainers. For an end-user it really doesn't matter who the maintainer(s) is/are, and it's more valuable to have a list of related modules by what the modules do than who wrote them.
I think it's a great idea to have a forum per module for discussion and support questions.
We'd move the code to the site, not the other way around
"Could a mock up g.d.o/project/foo be created?"
Sure. ;) I think the aegir group I linked to above is a good live example to start from for the basic idea. But, a more full-fledged mockup combining some of that functionality with some of the ideas over at Project node UI redesign (in particular, this mockup) would be most welcome.
"Could such an idea just live on g.d.o or would projects.d.o be better?"
I'm talking about enabling OG on whatever site hosts the project nodes. Presumably that'd be projects.d.o or code.d.o or whatever it ends up being called. I'm not talking about moving all 5000 project nodes to g.d.o itself. To the extent there are existing groups on g.d.o that serve as "project groups", we'd have to consider it on a case-by-case basis. For example, Aegir is actually a whole system that's based on a set of related but separate, stand-alone projects. So, that could continue to live as its own group, I guess...
"Each maintainer would have a group and then each project managed by that maintainer would be a sub-group of the maintainer group."
Down with subgroups. For starters, your model doesn't make any sense for projects with more than 1 maintainer, which we should strongly encourage.
+1000
I love the idea. As someone with a constantly changing project page, this sounds great. I'm always trying to pack info into it to keep people up to date on the status, point them at the docs, etc. All this would make it much easier and nicer looking.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
Project showcases
It would also be much easier to do "project showcases" or "3rd party write-ups" where a member of the general community could write a blurb about their use of this particular module.
If the general authenticated user had a place to discuss use questions for a module, then we might be able to accomplish 2 tasks.
It might mean a bit of fracturing of the community away from the forums though if we allow 3rd party posting into OG projects. Dunno if this is a bad thing or not since it might mean a realignment around the projects that are Drupal's lifeblood.
Out of the forums and into the project groups!
Having project-specific discussions centred around the actual projects would be a major step forward - pivots has helped a bit with this, but projects as organic groups brings it a step further. There are very, very few module/core contributors who spend any amount of time in the forums (and lots of the time that is spent is cleaning up moderating) - so new users lose out on expert advice, and maintainers never see what can often be very useful feedback or bug reports about modules.
It's also a lot easier to keep track of the support forum if you're interested in general helping out - certainly easier than the support queues of all the modules. Moving to a groups structure would hopefully mean that users of modules could help themselves with 'how do I do this?' questions more - which can often be answered by anyone who's been using a module to some extent, but currently fall on already overstretched maintainers a lot of the time (especially popular modules like views and panels). I'd say there's already a fragmentation between the forums and issue queues, and it's quite an unhealthy one - this proposal offers a way to close that gap significantly.
At the same time, Leisa's initial thoughts on the IA include combining the forums and groups into a community.drupal.org (no specifics, but something along these lines). If that was handled well, then it would bridge the gap in the other direction. If the forums get a lot quieter as a result of this, I think that's fine - since we'll have topic/task-based discussion in groups, and project-based discussion on projects* - which are the most effective places for that discussion to happen. As long as it's clear on project pages that these groups exist, it'll be pretty easy for people to find them (and less 'intimidating' than having just the issue queue).
Module related posts in forums
Yesterday, I was in the Drupal forums because the kids were to noisy to do any actual work. I decided to do a search on "Advanced Forum" and see what I could find. Unfortunately, search seems to return things randomly instead of more recent stuff first. I flipped back through 15 pages finding lots of forum discussions that I missed, questions I could have answered, posts I would have liked to have commented on. I'm in the forums a lot more than the average maintainer since the kids are too noisy to work a lot and the computer is on the kitchen counter so I pop in and out a lot. :) Anyway, I'm in there a lot and I still missed all those. It would have been so much nicer to have them all grouped together off the project where I could see them. I don't want all that in my issue queue, but using OG would give a great spot for it ouside of my queue.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
Yeah
Yeah that's exactly the use I was thinking of. You get the benefit of a casual environment for newbies to ask questions, and people to have discussions about improvements for the module, without having to go through and close a bunch of issues that are no longer relevant. Also, if someone makes a customization to your module that doesn't make sense as a new feature, other people will find out about it much more easily.
@dww: So I still have the
@dww: So I still have the same mental block when it comes to this as I did when we talked at the beginning of the summer. But...it looks like I should get over it :)
What block?
For the benefit of my failing memory, and of course the people who weren't at our meeting, can you articulate what "mental block" you have about this? ;) Thanks.
Picky picky ;) My mental
Picky picky ;)
My mental block was really at the notional level - that is, the mere concept of using OG to do this at all. Not b/c I don't like OG (obviously), but because I tend to think of 'groups' as being something...I dunno, different. It's really not a very well thought-through opinion, at least that part :P
A more technical opinion, insofar as I'm qualified to give one, would be that we are entering into slightly muddy territory with this. If we're just talking about d.o, maybe not such a problem, but if we're talking about 'the way forward' with project*, then I can say with authority that things will get sticky when it comes to utilizing Panels with project* that's built on OG, which is something we've also talked a fair bit about. Here's the picture if you just build on og_panels: because og_panels implements its own panels context type ('group'), if we wanted to start adding panels content_type plugins to round out the data shown on project* pages, we'd have to make those require the presence of a 'group' context. Which, from a UX perspective, could quickly get us into territory where the options presented via the UI are confusing and seem miscategorized, even though the underlying mechanics of it work just fine.
It's not that critical. What it really came down to in my mind is that project* is a different thing than OG, and though there are some overlapping needs and structural similarities, there's also enough that's different that it ought to be addressed separately.
But as I said, I'm happy to concede the point :)
Erm... YES!
I have to just ++ this idea right now. While I'd much rather maintain the blog on my own Drupal site, maintaining it as a g.d.o blog instead would be ok (and with a better aggrigator I could still get all the benefits of having that content on my site as well).
I love this idea.
Eclipse
+1
I come at this from a slightly different angle with the docs team. We are currently using a g.d.o group just to help organize ourselves and direct newcomers. If our actual project page on d.o would give us this, I'd be one happy camper.
Lullabot loves you
Learn Drupal online at Drupalize.me
Tabs!
We could have 4 default tabs, using Og_panels again.
In the view tab we have the module description, the links to download each of the major and dev versions, dependencies and some basic rating of the module using whatever metrics are agreed upon.
Documentation tab is pretty clear, and would certainly encourage a lot more documentation for our modules and make it much easier to find and use.
Discuss is this forum feature I talked about above.
Stats is a detailed breakdown of the important statistics involved with the project, download rate, average issue queue rate, developer reputation (however that is measured - maybe just some log function of number of commits?).
Project owners could then add a tab if they wanted, divide the documentation tab according to module version etc...
I'm thinking perhaps Wiki is
I'm thinking perhaps Wiki is another tab. And tabs would be optional except for View and Stats.
Do we want the whole OG functionality, or just panels?
Interesting idea, but I'm not completely sold on it. A panels-like functionality for project nodes sounds really, really nice, but I'm not sure the OG part of the package is useful.
...oh, and I almost forgot:
--
Hilde Austlid, Drupalchick
--
Hilde Austlid, Drupalchick
Discuss - should be no need to join
I think it should be possible to allow people unlimited access to discuss in the forums without joining the group. In fact project group membership should be exclusively up to the owner of the project, but would allow 3 levels of access.
a. All (ugh!)
b. Just this issue/forum post/documentation page
c. Version updates
Just one more thing
I like the idea, but I would like to point out one more thing to be modified compared to current groups setup: posting in multiple groups should be disabled/restricted. Just as now we see job offers spamming on 20 groups at a time we'd end up with support requests posted in ie views, cck, panels, ...
+1
Totally, totally and completely agree.
How do we distinguish
How do we distinguish between the issue queue, the bug report and the forums around a particular project/module?
OG is definitely a great idea. All subscribers should get mails and notification on any updates in the issue queue, bug report or support report if subscribed too.
We should have a tab to describe the architecture of the module, the scope for future hooks or growth, this could be a wiki and we can have discussion forums around it. Group for every module saying Redesign plan for the module_name will definitely be of great use for developers to colloobrate and expand the modules. Forums must be used only to collaborate new ideas or working on a new feature, like this group? We should not under value the effectiveness of the issue queue and support request.
Netlink Technologies Ltd
http://shyamala-drupal.blogspot.com/
Shyamala
Unimity Solutions
I'm behind this 100%. I will
I'm behind this 100%. I will change OG as needed to support this. We shouldn't feel limited with statements like "it is annoying to join a group in order to post". we could change that with a simple form alter ... This setup is in use at several consulting forms right now with more complex requirements than we have here (namely access control). I have no doubt that this will work.
Wiki page?
Maybe we should create a wiki page with a wish list of specific features, and then link these features to the active development of the same? It seems to me that we generally have support for this idea. Who do we need to convince to start moving it forward and into active development?
Dave
We need to convince the d.o redesigers
The first step is we need to make sure that these plans fit in to the overall information architecture and plans for the d.o redesign (which is why this discussion is posted to this group in the first place).
On the technical side, none of this is going to happen until the D6 port of project* is done.
So, sure, we could start a wiki page to hash out the details, but that might be slightly premature, since no one's going to be actively working on implementing any of it for at least a month, maybe more. Personally, I think it'd be fine to keep using comments in here for this brainstorming stuff, and when we're getting closer to reality, we can roll up our sleeves with a wiki to coordinate the actual implementation. But, if you're inspired to start one now, don't let me stop you. ;)
Cheers,
-Derek
we're listening!
don't worry - we're here and listening!
aside from the fact that I'm not sure what an 'Organic' group is (as opposed to a generic 'group'), this all makes a lot of sense to me and I don't see why we shouldn't try to integrate it into the redesign - stay tuned and help us work through the details v soon!
leisa reichelt - disambiguity.com
user experience consultant (design research and user centred design)
working with Mark Boulton Design on the drupal.org redesign project
leisa reichelt - disambiguity.com
@leisa
Organic groups
Lisa
I don't think there is a generic "group" that would be relevant to this discussion. Organic groups is a popular Drupal module (http://drupal.org/project/og) and is the module that is responsible for the various groups on groups.drupal.org. I'm not sure what makes those groups organic, but I guess organic is a good thing :)
I'm not sure why the module
I'm not sure why the module maintainer chose organic but these two definitions fit well.
http://en.wikipedia.org/wiki/Organic_(model)
http://en.wikipedia.org/wiki/Organic_(military)
In particular "organic refers to a military unit that is a permanent part of a larger unit and (usually) provides some specialized capability to that parent unit" if we drop the adjective military from the sentence it best describes the og module. But the Organic model states "Typically organic models stress the interdependence of the component parts, as well as their differentiation" which also defines what we have with g.d.o.
makes more sense now I know it's a module you're referring to!
thanks for that - it makes sense now that I understand that it is a module name :)
leisa reichelt - disambiguity.com
user experience consultant (design research and user centred design)
working with Mark Boulton Design on the drupal.org redesign project
leisa reichelt - disambiguity.com
@leisa
Drupalese strikes again. ;)
Sorry for speaking in Drupalese! ;) Shows that I'm hopelessly in the "insider" camp around here... The other folks cleared it up so I won't repeat them. Just wanted to apologize for making this post more confusing than it needs to be. I just edited the post to hopefully help clarify for anyone else reading this...
Cheers,
-Derek
groups, groups and groups
Should try to clarify exactly how this relates - the proposal is to install the 'organic groups' module on projects/downloads.drupal.org - and have every project be a group - so very similar tools compared to what's available on this site - so issue queues, but also discussions, would all be 'group postings'.
This would be completely distinct from groups/community.drupal.org - which happens to use the same module 'organic groups' - we'd have to figure out any duplication on a group by group basis - since some module maintainers have started groups.drupal.org groups for their modules ages ago.
Hmm, maybe not that clear ;)
Still viable
Note: this got punted as part of the initial d.o redesign implementation that was deployed, but I still think this is the way forward. Especially if there's a sane way to enable OG without it trying to do node access at all, I think there's basically no reason not to do this.
.
In D6, at least, the access control part is a submodule that does not have to be enabled if you don't want private groups.
Michelle
Still, still one of the most
Still, still one of the most exciting ways forward in improving d.o. collaboration tools!
A Great Idea that is Loooong Overdue!
Please vote for it at http://drupal-association.ideascale.com/a/dtd/Automatic-Project-OG/10341...