Tracking OG vs. Groups

Maybe I'm missing something but I don't see why you would need to create an issue to track a module? You could use the releases feed at http://drupal.org/node/711148/release

Yeah, it's a weird issue ;)

Maybe tracking the topic of OG vs. Groups is what BenK wanted to do? Either way, this seems like a reasonable issue to reopen.

What is the motivation of the name change? It seems weird to me. I think a lot of people are going to be supremely confused. There are also 20 pages of modules related to organic groups - do we expect them all to get renamed when they are ported to D7?

The reasoning behind the name change, was bringing OG as close as possible to the D7 standards. This was done in the code, and I felt the name should become more in line with D7 as-well.

I must admit that if there wasn't the Ubercart => Commerce example I would have been more hesitant. But looking at commerce as an example -- the code base has changed so significantly the name change is (IMO) acceptable.

For this reason I also think that OG modules that are still needed in D7 should create a new project prefixed with Group. Most probably their code will be considerably different than the D6 version, as most interaction with Group is done via Fields API. I'll ping DamZ and have his opinion on this legitimate question.

I agree there are times when it is necessary, but we should be cautious about it because it is likely to confuse a fair number of users.

My understanding is that the Ubercart vs. Drupal commerce was not simply an issue of changing the module a lot but also one of trademark problems and personality conflicts. We shouldn't use that as a guide of best results/actions ;)

Hi,

does this name change also imply that it will be more generic with respect to what kind of use cases / workflows it supports?

Given the vast number of integrated modules, a dedicated project taxonomy term, etc, I personally think changing the name is a really bad idea.

There is nothing wrong with a radical API change, but keeping the module name the same is important when the module is this widely known (and referred to in documentation and books) and when there are so many integrated modules that already exist.

e.g. for the Apache Solr Search integration project, we are already planing a 7.x-2.x branch that will totally rework the API and require a significant rewrite for any integrated module. However, there is no reason we would change the name.

@greggles, @pwolanin
I've created a poll for this module renaming -- http://gizra.com/content/should-organic-groups-be-renamed-group

Let's have the community decide on it. I am willing to go either way + there's a "compromise" -- to keep the name as is but to refer to it in te UI/ menu as "group"

That poll is closed whenever I visit. I think caching isn't working right which means that it's not capturing the sense of the community.

I also don't think a poll is a good way to make a decision like this.

The compromise makes a lot of sense to me.

> That poll is closed whenever I visit.

Strange, there are votes submitted.

> I also don't think a poll is a good way to make a decision like this.

I'm open to suggestions on better ways -- I've tried to raise this issue a few times

> The compromise makes a lot of sense to me.

Although it is currently getting little votes, it's also my favorite. @pwolanin what's your take on the "compromise"?

I don't really care about what it's called in the UI - I'm more concerned about all the cross-links and integrations - so that compromise would be fine for me. I mostly want it to remain part of the same "project".

Among several in-favor comments, here's Larry's (and supported by Sun):

There's nothing organic about them. The only reason to keep the old name is because it's fun to make caveman jokes about "Og". :-)

Given how radical the changes are, I think that would make the upgrade easier, not harder, since it can just view the old OG tables as foreign data to be imported as a one-shot-deal rather than treating it as an "upgrade".

That analysis places value on the things I think are least important. You could keep the project called "og" and rename the database tables as much as you want.

We have 20 pages of projects on http://drupal.org/taxonomy/term/90 and more everyday. Doubling that (which a change to "groups" would require) is a nightmare for end users trying to find the right module. The number 1 and 3 complaints of visitors to drupal.org in the fall of 2008 survey were both related to finding the right modules. Please consider that perspective and not just that perspective of people who live and breathe Drupal every day. Blog posts to the planet are likely to get the opinion of people like Larry and Sun who know every module by heart and it won't get the feedback of Suzie site builder who doesn't read planet...

Actually they are designed to be "organic" - I understand what it means in term so groups that are permitted to develop "organically", though I expect new users (and Larry?) find it less obvious and I'd agree that removing that term from the UI might be useful.

Perhaps a better way would be to organize the efforts into
Group - Organic
Group - Static

The second would allow less reconfiguration but better performance. It could be further broken out into pre-populated hierarchies like state - county - voting precinct which don't change often.

We need modules of counties for each state that would populate subsites for each county, complete with support for forums, calendars, and other functions to be administered by local chairpersons in each county.

Perhaps someone else has done this, but so far I have not found them in searches.

We are seeking a solution for national organizations with state and county chapters.

What I am looking for has been implemented at several sites. For example, using Zoomla we have http://www.givemeliberty.org/#states but there was a lot of manual work involved in doing that one. It starts with a map of the U.S. Click on a state and one gets all the counties in that state. Then click on a county to get the county page. But that one doesn't have calendars and forums for each county,

Another implementation of the kind of thing we want is http://www.wildapricot.com but they want to host, and we want to do our own hosting.

The main site, which uses Drupal/CiviCRM, is http://lptexas.org

Please contact me at jon@jonroland.org if you have a solution.

Moving discussion to g.d.o -- http://groups.drupal.org/node/75993

There were not enough votes in total, so OG will keep it's name in D7.

I'd support keeping the name, or at any rate not changing it to just Groups. The Feeds module is a good example of how information becomes near-impossible to search for once you make a project name too generic.