Problem/Motivation

groups.drupal.org is a complex site to develop and maintain. Currently built in Drupal 6, the site is due for upgrading to Drupal 7. Doing this upgrade as a custom site build would require a large investment of community time and resources.

Since GDO was first developed, a growing number of Drupal distributions have been developed, many having install bases in the hundreds or thousands.

Proposed resolution

Switching to a groups-based Drupal distribution would have several key advantages:

  • Make it easier for folks to help improve GDO. Right now, the path to replicating GDO for development purposes hasn’t always been clear, which means it's harder to help improve the site. If GDO ran off of a Drupal distribution, anyone could file a patch for GDO by filing one against the distribution.
  • New development invested in the site benefits multiple sites rather than just GDO.
  • By reducing the amount of custom code we run on GDO, we make it easier to maintain.

At the same time, switching to a distribution would raise some potential new issues.

  • Ability to make changes. As a standalone site, GDO is free to make and apply any changes. Being based on a distribution would imply needing to get at least some types of changes applied via a distro issue queue.
  • Availability in Drupal 7. Several Drupal distros are still in Drupal 6, with production ready Drupal 7 versions a ways off. Relying on a distro's upgrade schedule could mean substantial delays.
  • Upgrade path. While a distro may roughly match GDO functionality, it may impose greater or lesser complexity in upgrade path depending on how closely its architecture matches that of GDO.

Additional considerations:

  • Fit with specifics of GDO. Several common group-type functionalities - e.g., projects and tickets (issues) - don't fit in GDO due to the *.drupal.org division of labour.
  • Interoperability. To ensure that community contribution to the distro via GDO development has the highest application, the ideal distro would meet a high level of interoperability, e.g., through adoption and expansion of the Kit features spec.

Selection criteria to judge candidate distros

Criteria to use in selecting between candidate distributions include:

  • Distribution is group-focused and has (or can be expected to develop) functionality that closely aligns with GDO current and planned functionality.
  • Distribution is flexible enough that it will not impose functionality that is not appropriate to GDO.
  • Distribution is available in Drupal 7 or, failing that, has clear Drupal 7 upgrade plans with reasonably dependable timelines.
  • GDO admins are familiar with the distro and/or are active in its development.
  • Distribution has a significant install base.
  • Distribution is developed on drupal.org infrastructure.
  • Distribution development is community-based rather than being tightly tied to a single company. E.g., has community contributors and maintainers not tied to a given company. This is important even if current GDO admins have commit access to the distro, as this may change in future as volunteers or staff members move on.
  • Distro is developed in an interoperable way, facilitating component development that can be applied beyond the distro.

What distributions should we consider as candidates?

There are three distributions on Comparison of social and community distributions.:

Open Atrium Drupal Commons Voicebox
Groups based. Strong install base and development team. Includes some functionality less applicable to GDO (projects, issues). Groups based. Strong install base and development team. Current g.d.o. team includes Commons lead. Strong match with GDO functional specs. Community focused but not explicitly group-based. From bonobo: "As part of the team behind VoiceBox, I am very comfortable saying that the use case for which VoiceBox is designed does not match with the use case of g.d.o - there are some overlapping features, but VoiceBox does not attempt to meet the use case for g.d.o, and it is not going to develop in that direction."

Based on this evaluation, Commons appears to be the strongest match, with Atrium being an additional candidate worth considering.

Followup issues

Once a decision is made, followup to address questions identified in this issue can include:

Original report by ezra-g

I propose that GDO run on the Drupal Commons distribution as we move it to Drupal 7.

The main benefits I see here are:

A) Makes it easier for folks to help improve GDO.

Right now, the path to replicating GDO for development purposes hasn’t always been clear, which means it's harder to help improve the site. If GDO ran Commons, anyone could file a patch for GDO by filing one against Commons.

B) Align community development efforts

There's lots of community enthusiasm towards improving GDO. Similarly, the push to update Commons for Drupal 7 has begun, and I'd love for those efforts to also help push forward GDO. Many of the key modules and features between GDO and Commons are the same, so aligning the projects more closely seems natural.

C) Streamline GDO maintenance

By reducing the amount of custom code we run on GDO, we make it easier to maintain.

Comments

greggles’s picture

IMO, this is a great idea. One of the biggest problems to date in working on the site is:
1. Someone wants to help
2. We point them at a process that is pretty hard or grant them access somewhere that might get deleted
3. ...
4. sad panda

Having commons as a conduit to get a similar local site up and working should be a great improvement in the velocity of changes on GDO.

sreynen’s picture

I am excited about this.

webchick’s picture

As one of the people to whom #1.4 happened, +1. ;)

I don't know that we need much voting/discussion on this really, though. We have two maintainers of g.d.o: ezra-g and sreynen. If they both agree this is a good direction, we should Just Do It™ IMO.

webchick’s picture

Issue tags: +Drupal.org D7

Tagging.

pinkonomy’s picture

I agree,this will also make Commons a great distribution !

Anonymous’s picture

Awesome idea, yes please!

rachel_norfolk’s picture

This is a really great proposal - g.d.o benefits and so does Commons

Rachel

mariomaric’s picture

This would be totally win-win situation, awesome, +1!

jwalpole’s picture

I am a big fan of using the full breadth of social functionality of Commons and using a distro to make setup/maintenance easier. I would worry some that it puts a lot of implied support back on Ezra and Acquia (per Point A) but if that is manageable by Ezra, then I think the community still wins.

I think the biggest issue with g.d.o. in the past (and currently) is that it is not well integrated with d.o. (login/formerly theme/awkward nav, etc) if that can be fixed in the process I think that is most important.

webchick’s picture

Status: Active » Reviewed & tested by the community

Well that sounds pretty definitive. :)

greggles’s picture

Status: Reviewed & tested by the community » Active

@jwalpole - are those issues you're talking about not resolved? Please file separate issues (or even just mail me, I'll take them any format really) if there are still problems.

greggles’s picture

Status: Active » Reviewed & tested by the community

derp.

unleash’s picture

hello dear Mariomaric, hello greggles, hello webchick hello all!!!

great idea - great plan

You were right - this is an absolutly great thing - a win win situation. This cycle of testing and running and improving the code generates new knowledge and fosters the development.

i love drupal for its sustainable development.

keep up the great project - it rocks
greetings unleash

z.stolar’s picture

I'm all for it, as long as d.o. and it's git repository is where the latest code of Commons is being developed, and not on Acquia's website/repository (I believe this is already the situation, but just making sure).

bonobo’s picture

Status: Reviewed & tested by the community » Active

Hello, all,

First off, thank you for your past and ongoing work to make g.d.o the useful, fun community place it is.

The benefits of running g.d.o off a standard distribution are clear. And, the community benefits that come from working on the *.d.o infrastructure (pressflow and cod come to mind as two clear examples that were helped due to efforts within the community) are clear, and there is some precedent here.

However, Commons (the product) is closely connected and branded with Acquia (and yes, I am aware that g.d.o - the site - would not have this branding). With this proposed change, Commons will have advantages that other distributions do not have. Other distributions do not get the chance to get tested against a userbase of over 100K users, and do not have the ability to get feedback from a community of users who will be transitioned into the site.

In short, there are a slew of what can be perceived as competitive advantages flowing to Acquia here, and this has the potential to be a PR headache for everyone involved.

How will the community aspects of this be managed?

If the community aspects of this are not managed well, any benefits that come from any improved functionality could be eroded due to a loss of trust within the community. This is more than just a technical decision, and I would like to see us take the time to do it well, and avoid any blowback from rushing this.

Setting this back to active.

ezra-g’s picture

In short, there are a slew of what can be perceived as competitive advantages flowing to Acquia here, and this has the potential to be a PR headache for everyone involved.

I don't follow how running GDO on a distribution provides Acquia with a competitive advantage given that the code would be open source and available for anyone in the world to use.

Could you elaborate on what you mean there?

I also don't see why running a distribution on GDO introduces any new questions given that GDO is already running on community projects (eg Organic groups, Subscriptions, etc) that are maintained by developers with company affiliations.

What makes a distribution different from a contributed module in this regard?

ezra-g’s picture

To answer the question:

How will the community aspects of this be managed?

We plan to track work in this issue queue and the other places mentioned in the Drupal.org Frontpage announcement, which helps to ensure an open process.

bonobo’s picture

Hello, Ezra,

FWIW, I largely agree with what you are saying - as I attempted to make clear in my original questions, this is a perception issue.

A short list of some of these perceived advantages include:

* a large userbase that is getting funneled into the site; this would be incredibly useful for load testing, user stories, and seeing how elements of the UI and UX operate at scale;
* the PR value of having a product that is a central part of business and marketing outreach also operating at the core of daily community interactions;
* because of the prominence of g.d.o within the community, a larger body of developers contributing patches back to the project;
* etc -

Please, do not misunderstand - seeing g.d.o get some focused attention will be awesome, and this sounds like a great way to do it.

But, in the past Acquia has been criticized (imo, unfairly) for wielding an outsize influence within the community. I don't want to see that get repeated here.

RE: "What makes a distribution different from a contributed module in this regard?"

Complexity. Distributions are far more complex than modules.

webchick’s picture

If other project leads of other distributions that have similar feature set to Commons/g.d.o were stepping up to spear-head maintenance of groups.drupal.org, and were being told "no," then I guess we should have a discussion about whether Acquia is wielding some kind of undue influence here. But for now, we are handling this the same way we handle any community governance thing, which is do-ocracy. Ezra (who works for Acquia) and Scott (who doesn't) are both willing to maintain groups.drupal.org going forward, and both want to head in this direction for Drupal 7. Holding them up on community perception concerns strikes me as the road we don't want to go down, IMO, since it means disempowering people who want to do the work from doing so in the way that they feel is best.

jwalpole’s picture

Any decisions about what distro to use should come solely from what is appropriate for the functionality. In this case, GDO seems to fit the Commons model quite well.

jwalpole’s picture

Good point Greg. I am ummm embarassingly not sure if my general UX concerns are resolved - I sort of want to look at it more holistically. Certainly the theme matches now and the auth issues are fixed. Let me get more concrete issues + suggested improvements before I log an unhelpful ticket.

sreynen’s picture

Status: Active » Reviewed & tested by the community

As I said above, I'm excited about using Commons for GDO development, mostly because of how I expect this will help GDO. However, I don't see any problem with GDO also helping Commons. As Ezra said, Commons is open source along with all other projects on Drupal.org, which means anyone is free to contribute and make use of it in their business. The benefits listed above only seem to go primarily to Acquia now because Acquia has been the primary contributor to Commons. But a big part of this transition will be getting more people involved in Commons, which means more will share those benefits.

It's important that everything we're doing on GDO is in the best interests of the Drupal community, and it's great to see the community already watching out for that. I hope to see this continue as we get into specific issues with more actionable resolutions. I'm moving this back to RTBC, in hopes the general response here has been enough to address the general concern.

greggles’s picture

I am very glad that you are reviewing this skeptically, bonobo, even if you mostly agree with the idea. It is definitely important that this is given proper consideration.

Josh and I thought a bit about how we could make the site's maintenance work better than it has. We identified two big problems during our time as maintainers. First, there's the set of problem I lised in #1 that contributing by others is just too hard. Second, Josh and I have been less active than we should have been, especially in the last 6months-year (and I think that's being a little bit too polite in describing it, if anything).

Josh and I initially worked to fix the first problem by making it easier for other people to get a g.d.o site up and running. Josh spent time on our automation tools and I spent time making the sql sanitize script work well. We failed to ever really finish it and then we failed to maintain it and we failed to convince the powers that be that we should distribute the site broadly. While the answer for d.o is "develop on d.o infrastructure" that isn't as necessary for g.d.o (no solr, no git, etc.) and is still a lot of work compared to "Install Commons". I believe that using Commons as a way to get people on-boarded to adding features will be extremely helpful.

When we started brainstorming replacements we looked at the list of 25 orgs who do community building as a service and 25 who are in the Community sector and also just thought of potential people/companies beyond that.

The criteria we used was (quoted from an email I sent discussing this):
* 2 people from different companies
* Who work on sites with features like g.d.o
* Who either already have access to d.o's infrastructure or who likely can be trusted
* Who have a passion for g.d.o
* Who are good at listening to the community/being level headed/etc.

The reason we wanted people who work in this field is that we need people who know it and can make time for it. We need people who will prioritize adding features and making updates and trying out things on the "100,000" user base to make g.d.o better. It turned out that Ezra, Justin and Scott were some of the first folks we had in mind for the job and they were all excited to do it. We've seen what happens when there are maintainers who don't work in the space and it's not great (ahem). It's true Ezra/Scott/Justin will get to test out their ideas.

When someone else has ideas they can vet them through this issue queue and provide the code/configuration to get it done. Whether its Ezra/Scott/Justin or anyone else, those people will also get to see feedback and usage of their ideas. On the ideation/impact side, I have always been willing to run queries and make screenshots of google analytics for someone who is researching ideas related to community sites and if Ezra/Scott/Justin don't want to do that I'll keep doing it ;) That kind of stuff should probably come in the form of patches that add a metrics page (like #1182998: Provide a community metrics "dashboard") so it's shared with everyone, but I don't want to place too many burdens in front of folks.

If we look at other similar situations (maintainers of sites/infrastructure/team leads/module maintainers/etc.) in our community there are very high concentrations of representation from single companies or individuals who are in charge of an area. My believe is that this happens because 1) they are good at it 2) they are willing to do it. And those 2 facts stem from the fact that it's related to their job. That experience then affords them a) 'bragging" rights b) community visibility (the competitive advantages you mention). That model actually works well and I can't imagine how or why we'd move away from that.

I also just looked through the list of distributions that mention community and don't see any others with a feature set similar to g.d.o. Most of them mention community in passing like "Community.openatrium.com". Are we failing to consider a viable option? If there's something better than commons (or even close to Commons) then let's definitely consider it.

In summary: It was intentional to find people who work in this field so they can justify spending time on the area. The model that people who do the work get to learn from that work works well in other areas. Others are welcome to take advantage of that process. A little free attention seems like a very fair benefit. It also seems like Commons is our best technical choice.

bonobo’s picture

+1 on this.

greggles and others, thank you for the feedback here.

Seeing a community metrics dashboard for g.d.o, and as a contrib module (like in #1182998), would be awesome.

And, to re-emphasize: I never had any issues with the actual plan, and commons is a great technical fit for this. My only real area of concern was how this would land with the community when it moved out of discussion phase into implementation.

At the risk of laying the foundation for the bikeshed, it would also be great to see blog posts on the planet that describe the thought processes behind implementation decisions. Most people have no idea of the project management behind maintaining a site the size of g.d.o, and getting a glimpse into that would be useful for a lot of people.

nedjo’s picture

First off, absolutely, it makes sense to consider basing g.d.o off of a distribution. Yes, Commons is a strong candidate (though we have to keep in mind that specifics of Commons for D7 are at this point speculative).

However, this issue speaks eloquently about challenges that continue to face us in Drupal community decision making.

First, we still often skip to a particular answer before clarifying the question. Here, the place to start, pretty clearly, is not "Let's use Commons for g.d.o" but rather a series of questions: "Do we want to build commons off of a distribution?"; "What would be the issues/considerations of doing so?"; "What distributions should we consider as candidates?"; "How do the different current and planned distributions line up against the current and planned g.d.o functionality?"; "What would we need from a distribution to base g.d.o off of it?" By jumping straight to promoting a particular solution, we miss some important questions and discussion.

Second, we have a difficult time sorting out our different roles. Should we feel free to suggest and promote our employer's products for community usage? Absolutely. But, in doing so, it's pretty important that we consider, acknowledge, and communicate our own placement. If many or most of the strongest proponents of a company's products are employees of that company, that makes a difference and raises the bar for ensuring we're fully hearing and addressing questions.

There may be a strong case for thinking that g.d.o's needs closely align with the planned Drupal 7 version of Commons, and do so much more closely than for any other planned Drupal 7 distribution. But aside from some broad claims and a lot of +1 type comments, I don't have a basis in this issue for understanding that case.

What would we be saying if we were moving the main drupal.org site to a specific company's distro? Would the discussion so far in this issue be convincing? I'm (I guess it's obvious) sceptical.

Presumably, if we were asking the question of how existing distros line up against g.d.o. needs, the Comparison of social and community distributions would be a good starting place, alongside a list of g.d.o. functionality.

One of the key considerations IMO is: to what extent is a candidate distribution committed to, built on, and contributing to emerging interoperability standards like Kit and Open Apps? Yes, most Drupal distros are "open source". But if a distro goes its own way, development effort contributed to it becomes essentially proprietary code, in that it is usable only within the context of the particular distro. this was true for many D6 distros.

If, however, the distro is designed with interoperability in mind, enhancements may be generic enough to benefit sites based multiple distros and beyond.

mariomaric’s picture

As far as I can see the main issue is (was?) transparency of pre-decision making process for GDO @ Commons.

From Greg's post I can see that pre-decision making process had OK structure, but it was not visible / transparent to all other interested parties.

This is something that we can learn from, and from my experience development process for #1205556: [META] Commons on Drupal 7 have high transparency and everyone can get involved.

greggles’s picture

Issue summary: View changes

adding in some pre-discussion

greggles’s picture

Title: Have D7 GDO run Drupal Commons » Have D7 GDO run a distribution profile (such as Drupal Commons)

I don't think we should confuse the pre-decision making process of selecting maintainers with the pre-decision process on commons. The maintainers process was done with about as much openness as is standard for that decision.

A lot of the questions nedjo is raising are great ones that Scott, Ezra, Justin, Josh and I glossed over b/c they felt obvious to us. I've added them to the issue summary and answered some of them. I don't have the time to fully detail all of this and would rather not put 100% of the burden on the new maintainers. I'm hopeful others will join in and help edit that post. I don't feel like I understand the question "What would we need from a distribution to base g.d.o off of it?" - can you expand on what kind of criteria we can use to answer that question?

What would we be saying if we were moving the main drupal.org site to a specific company's distro? Would the discussion so far in this issue be convincing?

Did you know Drupal.org and D6 drupal.org sites run Pressflow?

juan_g’s picture

About possible candidates, in my opinion remarkable distributions with social/community features are for example those mentioned in the comparison page (comment #27), that is Drupal Commons, Open Atrium, and VoiceBox, and also some others such as Open Outreach (for non-profits) or Open Enterprise.

However, in the specific case of groups.drupal.org, this is essentially an Organics Groups site. Probably, for the D7 migration, an OG-based distribution would be advisable. This means Drupal Commons or Open Atrium.

Both are really worth to consider as candidates. OA is a special kind of distro, with its special ways for extendability, the interesting structure with the Spaces module, etc.; it's used more for intranets, project management, etc., but can also be suitable for community sites. DC follows more the standard, easy Drupal ways for extendability, etc., and seems more similar to groups.drupal.org. DC probably will be ready earlier for D7, and the new g.d.o maintainers are more familiar with this distro, but both DC and OA are indeed notable Drupal distributions, as it's well-known.

About the implications, possible advantages for some people, etc., I think that if a distro is chosen just because of its usefulness for the Drupal community, the developers of that distribution deserve it for creating an useful tool for the community.

webchick’s picture

Unless we have OA maintainers willing to step up and take on the maintenance burden of groups.drupal.org, that option is a no-go, as far as I'm concerned.

This isn't purely a technology question. This is a question of who is willing to donate the time and what tools work best for them, IMO.

juan_g’s picture

greggles wrote:

we failed to convince the powers that be that we should distribute the site broadly

That would be an additional, also interesting possibility: a new community-maintained distro ("Groups" or something) based on groups.drupal.org. Maybe not so easy to do, though...

webchick wrote:

This is a question of who is willing to donate the time and what tools work best for them, IMO.

I think that's right.

greggles’s picture

I've mailed Jeff and Karen B from P2 to get their perspective on this.

bonobo’s picture

As part of the team behind VoiceBox, I am very comfortable saying that the use case for which VoiceBox is designed does not match with the use caseof g.d.o - there are some overlapping features, but VoiceBox does not attempt to meet the use case for g.d.o, and it is not going to develop in that direction.

nedjo’s picture

@greggles: Re Pressflow, yeah, I wasn't thinking of that in the same category, but good point and worth remembering.

Re

I don't feel like I understand the question "What would we need from a distribution to base g.d.o off of it?" - can you expand on what kind of criteria we can use to answer that question?

One thing I'm thinking here that whatever distro we choose will be a step forward in that development effort that was previously available just to g.d.o. will be available to any users of the distro. So far so good. But we can and arguably should aim a bit higher. Rather than silo off our community efforts in a particular distro, ideally we'd be collectively building something that works on g.d.o. and is also applicable to any other site, based on a distro or not. That is, the ideal distro would meet a high standard of interoperability.

Which is going to take some work from all of us. As distro authors we've focused a lot on our own work but been pretty much slacking when it comes to the work of achieving interoperability. Case in point: plenty of references to the Kit spec, but none of us has even updated it to D7.

To help discussion forward, I've opened a set of related issues and pages. Please review and improve!

If we can achieve a high level if interoperability, the issues bonobo flagged in #20 will be much less of a concern--development efforts and community contributions invested in the chosen distro will have applicability to related distros as well.

greggles’s picture

Status: Reviewed & tested by the community » Needs work

Great points, Nedjo. My only hesitation is that this seems like a bit of extra work - more so up front than ongoing - and I think our main focus should be on getting things done. Moving this back to needs work for
1) any more work people can put into answering the questions in the issue summary (i.e. the original post)
2) hearing from Jeff/Karen about their opinion on the suitability of OA and availability of support to make that work

greggles’s picture

Issue summary: View changes

distinguish original convo from added questions

nedjo’s picture

Issue summary: View changes

Update summary.

nedjo’s picture

Updated the summary. Could use more detail about Atrium and Commons (see the table cells for each). At this point Commons looks like the strongest candidate. Would be good to get further detail on fit or not of Atrium before signing off a decision.

bonobo’s picture

As part of this work, when will the code for commons leverage the new packaging/distribution functionality on d.o?

The current release page points users to download the distribution from the Acquia site.

One enormous benefit of having g.d.o running on commons, and commons using the d.o packaging functionality, is that it would bring more eyes onto the packaging work. It's pretty awesome, but there are still a few small issues that could benefit from more eyes on them - #1482888: Support 'subtree' download attribute for libraries comes to mind as a practical issue that will need to be addressed at some point.

ezra-g’s picture

As part of this work, when will the code for commons leverage the new packaging/distribution functionality on d.o?

The current plan is to do all of the Commons D7 development via the Drupal.org packager. I'd like to see us move the D6 version of Commons to the Drupal.org packager, but we're focusing our available resources on D7 (and GDO maintenance) at this point.

bonobo’s picture

RE:

I'd like to see us move the D6 version of Commons to the Drupal.org packager, but we're focusing our available resources on D7 (and GDO maintenance)

If I was in your position, I'd leave the D6 version as-is, and focus on getting the D7 version onto d.o.

unleash’s picture

1+ bonobo
If I was in your position, I'd leave the D6 version as-is, and focus on getting the D7 version onto d.o.

sure thing - the future is ahead - not behind.... so lets work on the sustainable tree of development... and this is the version 7.....

the future is bright - looking forward...what comes

mariomaric’s picture

After I read My Thoughts on Open Atrium 2 from Patrick Settle there is no doubt that Commons are the right tool for the job a.k.a. GDO.

Focusing on what Open Atrium does well can allow us to hone the included features and user experience even more providing a best in class project management tool.

IMHO, this issue should go back to RTBC, as we fulfilled all points from #36.

Let's focus on getting things done! :)

juan_g’s picture

Yes, also according to other of their recent documents on the next Open Atrium 2.0 [pdf], to be developed for D7, it appears that the new OA team is planning to focus less on flexible, general purpose, and more on specialized, out-of-the-box product for OA's frequent use case of project management:

While many use Open Atrium as an Intranet or a micro-site platform, Phase2 believes the focus should be on improving the current toolset to bring the next generation of project management to Open Atrium users and to create a more comprehensive, out-of-the-box project management tool.

And, for the new version, they will be renaming the former "groups" as "projects".

An additional point is that, although it's indeed possible to customize Drupal Commons or Open Atrium to run groups.drupal.org, OA surely would require more customization work, while Commons features are already nearer to g.d.o specifications.

Of course OA also has advantages, like the Spaces module, which opens so many interesting possibilities of functionality for groups, etc. However, there is now the OG Features module, developed for Commons as an alternative to Spaces. For details, see #1196422: When to use og_features instead of og_spaces?

juan_g’s picture

greggles wrote:

I've mailed (...)

Is there any reply? Maybe I'm wrong, but I'm thinking that, if the OA team hasn't replied about this issue these past two weeks, it's possible they have considered it answered already on their previously mentioned, recent documents about the new less generic, more specialized orientation of Open Atrium for the next D7 version.

greggles’s picture

Status: Needs work » Reviewed & tested by the community

I did not hear back from them. I'm setting this back to RTBC , but think it could be marked fixed. I know we haven't finished all the sub-issues and we haven't answered all the questions that should be answered in an ideal world, but I'd like us to let progress continue even without finishing everything.

nedjo’s picture

Status: Reviewed & tested by the community » Fixed

@greggles: agreed. The extra review we gave this issue spun off some useful discussions that can continue. There's a good consensus here. In any case, community review is for the good, but the key piece is the people doing the work, who are clearly on board. Let's call this fixed and not hold them back.

unleash’s picture

hello dear all

many thanks for the hard work - the future is bright - guess that thousands of drupalers from all over the globe is waitin for the new version of drupal common - the common on D 7

guess that the new version will be released within the next 3 to 4 months -

the future is very very bright. i really am in a enthusiastic mood.

greetings unleash

Status: Fixed » Closed (fixed)

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

ezra-g’s picture

We posted an interactive prototype of the redesigned 3.x version of Drupal Commons that would power GDO at http://groups.drupal.org/node/244663.

juan_g’s picture

Commons 3.0 for Drupal 7 has been fully released two days ago. Good job!

juan_g’s picture

Issue summary: View changes

Note projects and issues in Atrium.

Umar03260’s picture

please i can't see the auto run at the drupal 7.38 for installation on my computer for
me to get started, if there is any alternative please i need help.