Many of the projects included in the Commons tarball exist as their own Drupal.org projects with their own repositories and issue queues. A main goal of this approach is to make it easier for site builders to start a new site with only the Commons components that they need.

One potential drawback is that issues that affect the distribution's Commons_* code are spread out across multiple issue queues, which makes it more laborious to answer questions such as:

- How can I see a list of Commons issues so that I can help with the distribution?
- Has this bug already been reported?
- I'd like to file a new issue against Commons - Where should I do this?

One way of addressing these issues would be to use the issue queue for the main Commons project and to create a component for each of the other sub-projects.

Benefits: It would make it easier to answer questions such as the ones above.
Potential Drawbacks: It's a slightly unconventional way of using the issue queue, and we'd have a heckuva lot of components.

What do folks think?

Comments

Topcheese’s picture

+1, Your drawbacks supports the benefits. It would seem having lots of components listed in one spot would be easier to manage than having them spread out over lot's of issue queues. Could be unconventional, it could be pioneering.

webchick’s picture

How we [try to] handle this in the Spark queue, which is similarly architected to Commons, is we keep a "postponed" issue in the "main" Spark issue queue for any bugs we know about that links off to the "right" issue in the right place. This is a similar approach as well to what we did with http://drupal.org/project/git_dev during the Drupal.org Git migration which helped abstract something like 12 other possible issue queues that without intimate knowledge of how everything was constructed, you never knew where things were at.

This approach makes it so that "end users" only have one issue queue to file/search for issues, but the actual implementers can spin off as many sub-issues as they need in whatever queues are most appropriate to organize/collaborate on their work.

In the case of Commons though, where the sub-modules are all ones you yourself support, and there's not a lot of reason (I think?) someone would use commons_pages, for example, outside of Commons, another approach is just to turn off the issue queue functionality in those projects and make each sub-project a Component on the main Commons issue queue. This would give you the same "filterability" as well as provide a centralized place for people to collaborate. We didn't do that with Spark, because Edit, Aloha, Layout, etc. are specifically engineered so that they can be used in other distributions, or just added onto an existing non-distro-based site so for us it makes sense to have separate queues.

In any event, though, +frigging one for the concept. This was easily one of the biggest barriers to getting started contributing for me; just trying to figure out where everything was at.

webchick’s picture

Btw, on the "heckuva lot of components" drawback, a heckuva lot of components is vastly superior to a heckuva lot of dis-jointed, separate projects which, without trawling through drupal-org.make or hoping they're all documented on the Commons project page, is impossible to find otherwise. :)

lisarex’s picture

+1 for having a single issue queue, particularly if the goals are to make it easier for people to contribute, find answers themselves etc.

webchick makes a good distinction: Is the module likely (could apply our favorite 80% here) to be used only with Drupal Commons? If yes, keep it together.

ezra-g’s picture

Status: Active » Reviewed & tested by the community

webchick makes a good distinction: Is the module likely (could apply our favorite 80% here) to be used only with Drupal Commons? I

I'd say yes, 80% or more of the time, these modules will be used in Commons. They could be used independently of Commons, or by someone who wants to add selective Commons features to a site that didn't start with the Commons install profile.

I'll start moving over issues - This feels like a bit of a relief :).

webchick’s picture

One quick thing before re-jiggering the components list.

Is it possible to keep the "human readable" versions of the names like you have now? E.g. "Groups," "Radioactivity," etc. rather than getting all precise about it like "Commons Wikis" etc? That'd really help w/ the approachability I think. It makes it a little trickier what to do about modules like Commons Pages, but maybe that could be roped into a general "Misc" category?

ezra-g’s picture

Status: Reviewed & tested by the community » Fixed

Yep, I'm keeping the human-readable versions of the names.

Let's see how the revised list of components works and we can always add new ones as needed.

Thanks for the input, everyone!

webchick’s picture

YAY! Thanks, Ezra!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.