Should Organic groups be renamed to Group?
EDIT: Poll has moved to Drupal groups
Weird, but I haven't thought about making a poll. Luckily, since Drupal7 is still not released there is time to do changes -- and maybe revert them.
So, what do you think, should OG be renamed to Group?
No - It will cause too much confusion and will make upgrade too difficult
19% (11 votes)
Yes - Changing the name to be D7 standard like Node and User is important
73% (43 votes)
Keep the module named OG but in the UI call it 'Group' (Like node is being called 'content').
8% (5 votes)
סך הצבעות: 59
תגובות
User Group
I will also suggest User Groups as this is more friendly than Group which looks more general and that might be a bit complicated. Web design
3rd option
In favor of those that don't follow the main discussion I tend to go with the 3rd option - to keep OG module name as is, but in the UI/ menu/ entity name call it group. The main reason is that not enough people have voted, and I'm "afraid" to do such a major change based on so little voices.
+1 for Group
I tried voting a few days ago, and I tried again today, each time the poll was closed.
+1 for "Group".
Much clearer, especially when considering new users (the "organic" part was always needlessly confusing).
Also, +1 for the new code, concept, communication, and your efforts. It is appreciated.
Central place for discussion
Let's move the discussion to http://groups.drupal.org/node/75988
I believe it will be visible to more people.
FYI, Some discussion was
FYI, Some discussion was split to this issue -- http://drupal.org/node/794312
I think maybe we should move this poll/ comments to a single place, maybe the front page of g.d.o -- so this will get a bigger exposure. Many people/ contrib will be influenced by this decision.
User Groups
I suggest User Groups.
Using only the word Group is too abstract.
Since things can be placed in groups, adding who or what is being grouped in the module makes it clearer.
Nope - we have only two
Nope - we have only two options OG Vs Group.
Conflicting choices
Groups is indeed much more understandable than OG, but this comes with a practical downside: it is currently much easier to find something OG-related with a search engine than it will be if we switch to Groups, which is a much more commonplace term on the web.
> it is currently much easier
> it is currently much easier to find something OG-related with a search engine
The same issue will raise from the CCK => Field/ Ubercart => Commerce change
"Groups" is unquestionably
"Groups" is unquestionably more confusing to refer to but easier to find/learn. It's very clear what you mean if you say "OG" whereas if you refer to a "group" the meaning is not so clear. Yet "Group" seems like the much more logical choice for a module whose purpose is to provide groups. So +1 for logic, -1 for clarity?
I have the same problem with the Feed and Views modules.
+1 for groups
+1 for groups
+10 for the communication and overall effort you've been putting in to this
> +10 for the communication
> +10 for the communication and overall effort you've been putting in to this
@Lior,
Thanks for the compliment! I do hope people will like the new OG/Group - the use of Field API has brought *many* goodies to it.
"Organic" just confuses people
Saying "organic" is like saying "Form API". It just makes people's eyes glaze over and they back away slowly.
Yes
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".
^^
What Larry says.
Agree, it's User and Node so
Agree, it's User and Node so it should stick to that. Totally think its a good name change...in the 7 branch and beyond. That way there aren't any conflicts with modules currently depending on (or looking for) OG
my vote is for Groups plural.
my vote is for Groups plural. When using OG the point is to have more than one group.
Groups
Do you think "Groups" like Views, Panels, Feeds, Features, Rules,... ?
It is tempting, but contrib
It is tempting, but contrib should imitate core as much as they can. In Drupal core that names are singular.
I also think Groups sounds
I also think Groups sounds much better than Group. Just as Feeds sounds much better than Feed.
Sean Bannister
Entity and DX
Entities are singular. There is one entity you are working with; a node, a user, a group.
Compare:
node_save()group_save()
vs.
nodes_save()groups_save()
The fact that you can have multiple groups and not just one does not mean that you need a Group API that knows how to handle a single group in the first place, before trying to handle multiple.
Some of the plural-form project namespaces were caused by already registered/existing other projects. For example, see http://drupal.org/project/feature -- everyone bear in mind that projects can be re-owned and re-purposed, if there is a maintainer and community agreement.
Is a group an entity on
Is a group an entity on Drupal 7?
Nodes, users, and taxonomy terms, are examples of Drupal entities. But IMHO Groups, Views, Panels, Features are "tools".
groups_group_save()groups_group_content_save()
> Is a group an entity on
> Is a group an entity on Drupal 7?
Yes.
> groups_group_save()
It is group_save() -- like node_save().
> groups_group_content_save()
No need for such a thing. The group is "living" inside the field API -- see group.field.inc
...
All entities: a view, a panel, a feed.
Not sure what a tool is, but sounds like everything is a tool.
Drupal entities != stdClass object
Then Drupal entity == stdClass object ?
D6 content types (node) => D7: entities (node, user, taxonomy + contrib "fieldables")
...
I'm not sure what Anonymous tried to ask. The math is obviously wrong.
A stdClass object has no defined schema/structure. Content types ain't entities.