In order to loosen up the policy on creating groups we need some better tools. Let's brainstorm the problems and potential solutions.
How about:
1. Allow easier curation of topics into/out of groups
- the Og_actions module could help us here if we had a tab on a a node to initiate the "add to my group/remove from my group" action.
2. Make it obvious which groups are "ghosts" and also which are hot
- http://drupal.org/project/radioactivity could help identifying each of these
- Then we need some blocks/theming for "ghost" groups that points people to a list of related groups that are hot
- Flag/Flag Note could be use to allow community members to flag groups as ghosts
3. Promote uniqueness in group submission
- http://drupal.org/project/uniqueness ?
- http://drupal.org/project/similargroups could help after the fact
4. Make the approval process more transparent and distributed
4A. Include voting as part of the approval process
- Voting on a group using fivestar+comments would be tied to commenting, so people could comment on the group as they are rating/voting. This meta group discussion could be moved to a "Talk" page to hide it from most visitors to the group.
At the end of the voting period, the group would be approved- A new "flag as inappropriate" with the Flag module and a corresponding view that works on nodes, comments, and groups to help limit "scams and NSFW"
4B. No Approval Needed Automated Groups approval
- When a person proposes a group, it is
open for review for X days.approved right away Auto-approve a group after it reaches a critical mass of members (StackExchange-style).(removed in light of the above modification.)
4c. Move new group proposal process to GDO issue queue
- Rather than dealing with proposed groups in a private moderation queue and opening public issues on disagreements, start the process in the public GDO queue.
5. Make it easier to merge groups
- This is already handled by OG core since November of 2009! It can merge users and posts from a deleted group into another group.
Comments
Picking up the thread
I'm sympathetic to this viewpoint:
The biggest reason I think moderation is important is to prevent splintering and sub-grouping. I think in real terms, as long as we can agree on what sorts of things fall outside community standards (e.g. marketing scams, anything NSFW, anything derogatory) we should consider a more permissive standard for groups, possibly with reactive rather than proactive moderation. E.g. anyone can make a group, and the moderators will review these after the fact and/or in response to flagging.
The one thing that would be great would be to help drive convergence: some way to encourage people to join existing groups rather than starting their own. That shouldn't be too much harder than all those tools for bug reporting that try and prevent duplicates...
https://pantheon.io | http://www.chapterthree.com | https://www.outlandishjosh.com
voting
Thanks Greg for devoting some time to start and share this list of problems!
Voting -- in the up and down have-an-election sort of way -- isn't something I'd be keen to see. Maybe if voting is simply a +1 thing which says "If this group exists, I'd join it." But what does a group need? 3 people? 10?
I've never used the modules you listed, but I'd be willing to spend a few hours with them next week if we need to do research.
I am most concerned that people will not review the list of groups before creating a new one. I think this is the main value of moderation in addition to preventing totally wrong groups from being created. There should still be a high threshold for creating groups to avoid making a mess of groups.drupal.org.
I wonder if there is a module to merge groups...
Merging groups
Merging groups is pretty straightforward, at least from a content place. When a group is deleted, all of the nodes in the group can be specified to go into another group.
Although I'm not sure if members also transfer.
FunnyMonkey
users cannot (yet) be merged
See http://drupal.org/node/197957
knaddison blog | Morris Animal Foundation
some (or all) of the groups
some (or all) of the groups you listed as exceptions should have been denied by our usual standard. There is clearly not 100% consistency in the groups moderation process since it's done by various people in bursts or on occasion.
The hard part I find about uniqueness is when there is a proposal for a new geographic group that turns out to have high overlap with existing groups. That's sometimes only clear after research. It would probably be helpful to try to recruit more moderators from Europe, Asia, South Asia, etc who might have a more intuitive sense of what useful geographic grouping would be.
Asking people to submit a statement describing their search criteria for existing groups might be a good step.
If you delete a group, og can merge the posts and users into another group - I think this is a solved problem.
Definitely no duplicate regional groups.
I think we all agree what pwolanin wrote here about duplicate/overlapping groups specially when they are regional, which results in confusion, sometimes I wish if groups were made like CVS accounts (given on demand) but that would be really going too far and not at all in line with drupal's vision. For example there are 2 pune groups for the city I live in --
http://groups.drupal.org/pune
http://groups.drupal.org/pune-india
With former having less members and usually cross posts. I even had a problem couple of months ago when India group was not at all available - http://drupal.org/node/690366 as someone created another group with the same name (bug couldn't be reproduced) and locked out the india group for more than a week.
Another examples of exactly similar groups --
http://groups.drupal.org/summer-training-india-organizing
http://groups.drupal.org/summer-training-india
I would be happy to help in moderating groups from india, but we dont have region segmentation built into the system right? Like there is no way to find groups region wise.
Another place to look for similar and sometimes overlapping groups is taking the intersection of cross posts done by members, This could also be used in recommending groups?
Dipen Chaudhary
Founder, QED42 http://www.qed42.com Drupal development
Disagree on the CVS like
Disagree on the CVS like handling, but on a mostly side note what I would love to see is more geographic display of data, like maps/location search of where groups are located, and even more, where events are located. For example, I know there is quite a few drupal camps happening recently, but unless they crosspost, or I subscribe to every group near me, it's hard to find out some information. But that is off topic.
But +1 to opening d.o admission policy. It bothers me that some current groups are mis-categorized due to the lack of appropriate categorization (:O).
---
I agree that moderation is necessary, but I don't see how it's possible for a module to filter out the groups that should not be created from the group description. Clearly there should be a user that check the description, and who decide if the group deserve to be created. As there are many users who approve the group, it's possible that some groups get approved, and some other groups don't get approved (even though the approved one seems similar to the ones that don't get approved).
About the geographic groups, I notice there is an Italian group, and a group for Florence (Italy). The problem is this case is to understand which is the minimal distance that should be considered for the two groups to be duplicated. If I would have to go to Florence from where I live (I am a way more northern than Florence), it would take me between 2:31 hours and 4:42 hours by public transportation (between 3:08 hours and 3:44 by car). I would probably like to see a group that is based on the same province I am, and create a group called .
Also in this case, the approval of the group should be taken from a user who is able to decide if I can possibly go to meeting at Florence, or not.
My point is that the approval of groups depends from users who need to give the right interpretation to the rules set.
I am not sure that loosing up the requirements is the right way to proceed. In this case, there should be a group of users who are single (because users who are single have possibily different issues to live with than married users); or there would be users who want to create a new group just because they are the manager of the group, or just because in that way they have a group that is all theirs.
Groups police
The discussion on http://drupal.org/node/805888 reflects a real problem, and I'm glad to see this thread here.
As an open community, it seems that getting a group approved has become almost a Kafkaesque process of rules and precedents that all contradict each other and sometimes even themselves.
I'm very much in favor of a more open policy about groups. I find the "I can't see the purpose of it" argument to be rather uncompelling. If you don't find the group interesting, then don't join it! If you don't find it relevant to your interests, don't join it! I don't see the big deal, as long as the group doesn't violate general Drupal community policy.
If a group overlaps or duplicates another, it can be deleted and merged into the other group. If a group is quiet, then it can be deleted and merged into a related group, or closed as past its time. If a group is active, then great!
I like the groups recommendation ideas. It will help the accidental duplication that can happen. OG similar groups module seems like it would be a nice add-on, too.
PINGV | Strategy • Design • Drupal Development
+1 for everything Laura said
The Design for Drupal group took over a year to get approved. And when I say approved I mean the original request was denied [those were exciting times if you remember the hot discussions in IRC] and only when a more prominent member of the community requested again [a yr later] and was backed by yet another prominent member did it get approved.
I believe loosening the acceptance rules will serve us well.
CAVEAT: I'm the leader of the Indiana group and we kind of have a group trying to form on Purdue campus and way down south in Evansville Indiana. I would not be in favor of creating two new groups for them. If they did, I believe that ALL members of the Indiana group would immediately join it and 99% if not 100% of the posts would be cross-posted. I see that as very wasteful.
I support the use of panel-pages and taxonomy to create easy navigation of not only ideological segments of a a single group but even the geographical segments as well.
I did this for the http://groups.drupal.org/curriculum-and-training group when I created the Open Curriculum tab where all posts of that very ACTIVE topic reside. We could have easily started our own group but we chose to utilize the Curriculum and Training group.
Agree with dougvann about over-lapping regional groups
http://groups.drupal.org/connecticut
Is one of I'm sure a number of examples of groups that serve different local communities. In the case of CT we have used taxonomy and panel panes to distinguish this. So far so good. I'm hopeful this strategy will allow our "larger" group to collaborate when needed (for example in planning the first ever DrupalCampCT).
With great power...
This also makes me think: we may want to highlight the fact that running a Drupal group means taking some responsibility. Get people to think a bit bigger about it, and maybe work on improving an existing group rather than creating a splinter.
But different geographies have different needs. Here in California, one big state group would be totally unworkable. :)
https://pantheon.io | http://www.chapterthree.com | https://www.outlandishjosh.com
Sustaining d.o's interests
I absolutely agree with Laura; I would add the following points:
It is in Drupal's interest to let as many people associate with it on the d.o domain directly. If their request is rejected, it will not reduce the need for association but will simply move it elsewhere out of reach, possibly creating a trademark nightmare when it comes to associative domain names. IOW, it stops nothing, it just chases people away. That's not what we want.
The cost for hosting a group is infinitesimal; if people see value, it will thrive. If not, then not. The cost will certainly be nothing compared to the policing of regional, lifestyle or activity-based domain names including the word "drupal" in the future. We're creating a greater problem ahead by not addressing a small problem now.
The limitations should only be applied to groups that would violate the open nature of Drupal; shill groups, spam groups, clearly commercial groups, and the like; it should be a permissive type of policy rather than demonstrate-your-worth approach
The demonstrate-your-worth approach is entirely arbitrary; it means that we must present groups in a way which appears satisfactory to whoever is in position to evaluate that group, no matter how unfamiliar these people might be with the sustaining values and philosophies of the group seeking association. Case in point: 5 of us met at the last DrupalCon and decided to host a Drupal Skydivers meetup at every DrupalCon thereafter, even inviting new people to try the sport if they felt like it (we joked that it was a lot less scary than putting D7 in prod). The odds that the group moderators are familiar with, find value in, or even have a correct understanding of skydiving are slim to none (it is a lot less dangerous than riding a bike or driving a car for instance, and this is statistically true regardless of the moderators' views on the matter). Why should their views on the matter, not borne of experience, restrict the ability of people who understand and want to meet each other to keep meeting each other and organize valuable activities for the community ? Why is it that a group like Drupal Fit is acceptable yet Drupal Skydivers is not ?
the arbitrary nature of group approbation, and the poor light cast on the process, does not give an impression of openness or justice; it fosters the idea that cliques and connections should prevail rather than the greater interest of letting people freely associate with Drupal. This casts an uncomfortable shadow on rejections, and unfairly tarnishes the legitimacy of acceptations.
Who votes?
If voting were be used as criteria for whether new groups were accepted then I think there should be a distinction made between admin / known/trusted contributor / infrastructure contributor versus normal users rather than just a blank requirement of X votes. Rationale: to avoid undesirable groups (nsfw, hate groups, "kitten killing" taken too far, etc) being added en masse.
normative vs. positive statements
The first three problems/goals are items I created and they are normative problems without mandating a solution to the problem:
The last item is a positive - it says what we should do but not why:
Could someone clarify what the goal of this feature is? Then we can discuss whether voting is the best way to solve it.
knaddison blog | Morris Animal Foundation
Thoughts on voting/rating
As I was the one to add in the idea of voting, here is some of what I was thinking -
Some form of community voting/flagging could help make the approval process more transparent (for example, a group gets approved after X people indicate an interest in seeing the group get approved).
It would also be useful to introduce a combination of Flag/Flag Note to allow community members to flag groups that appear to be ghost groups (although really, some of this could be automated: if a group has no comment/no nodes for 90 days, the group manager and gdo admins gets emailed about the status of the group).
In any case, voting isn't the be-all end-all solution here, but it could be used to make the process more transparent and to empower people within the community to get involved.
FunnyMonkey
Or don't moderate
I honestly think we should consider doing away with the "needs approval" moderation workflow. If we can find another way to automagically suppress fragmentation and make merging easier, we could make this thankless/capricious task a thing of the past!
https://pantheon.io | http://www.chapterthree.com | https://www.outlandishjosh.com
seems good to me
I think "don't moderate" and then provide a simple "flag as inappropriate" and the ability to have meta discussions on the group itself will help us identify the really bad (MLM/Spam) and the moderately bad splinters and such (Drupal for Post Grad Students who Support CSA in My Small Town).
I've added those as concepts on the wiki.
knaddison blog | Morris Animal Foundation
That will be tricky
We will always fight fragmentation and it's quite hard to set up rules for that...
redefining/expanding existing groups?
i recently had a request to create a new group denied. at drupalcon there were several of us who wanted to make a group that was more of an umbrella group for environmentally related drupal projects. we had a discussion about names and tried to vote on the names. (garden geek won in our tiny poll, but i still think the group should be more inclusive to not just gardening) my request was rejected, even though i outlined the kinds of things we would discuss in our group - which were conceptually different from existing groups. no explanation was given except that it didn't fit the handbook. i assume this is because drupal for community supported agriculture sounded similar.
fortunately, greg heller let me be an admin on the drupal for community supported agriculture group - this was the closest group to our proposed group - and also contains some of the same members. we can use that group for what we will be talking about this summer - and i'm fine with that for now.
however, that group still isn't the proper conceptual framework for what i wanted to talk about with the larger drupal community. and i'm not sure what process to go through in order to expand the group. my plan was to start inviting people to that group and tell them the group really isn't about just CSA's. i agree that fragmentation isn't very helpful - but i would like a group with a larger mission so that discussions seem appropriate to that group.
not sure how to proceed.
my questions:
* it is OK to change the mission of a group to be more inclusive of other topic areas after its already created? has anyone done that before?
* how do you expand a group that already exists?
* how do you group groups? i would like it if there was either an environmental group or a set of groups that are environmental - like garden geeks, drupal for CSAs, bioinformatics...and others that might happen. people do use drupal for projects related to this and i would really like to have a space to talk about that.
Just my opinion here on the
Just my opinion here on the specific case for Chach's question -
It seems really odd that the CSA group would need to be amalgamated for such purposes, as it's a very specific case in its own right.
Why not make a new group called /green (or something more creative) to umbrella any green/sustainable/environmental projects? Seems a lot more appropriate than commandeering the CSA group (as much as it was nice of Gregory to help out, and the specific garden project does fit much more there).
that's what i was thinking...
that's what we had tried to do...and the application was rejected. (i might revisit our poll to see if we can change the name, we only had a few people actually voting on the names though we talked about it a lot.)
Two more things related to this subject:
Where are we supposed to go to contest group rejections? (IRC? this group? just keep reapplying?)
Any chance rejection emails could say which criteria the group application didn't fulfill?
I'm not sure how the applications are reviewed, or if reviewers have the tools to give feedback, but this was the email i got:
"Your Group entry entitled "Garden Geeks" has been denied by our content moderator. Our group guidelines are posted at http://groups.drupal.org/node/add/og. The content has been deleted from our site.
Note:
This does not meet our guidelines for groups:
http://groups.drupal.org/node/20724
Regards,
The groups.drupal.org team"
it is OK to change the
I think that's fine. I do this quite often. Usually post a discussion node in the group to propose the change and then do it.
I think if we have a group like the CSA group that is perhaps overly specific that you can expand it and use a group specific vocab to keep track of specific sub topics. There's a post somewhere recently about how to do this, I think from winston.
Edit: The thread was here: http://groups.drupal.org/node/45072#comment-216423 about how to edit panels effectively
knaddison blog | Morris Animal Foundation
What's a splinter
Indeed, even if we revamp our guidelines to be more open the question of what qualifies as a "splinter" is still pretty subjective. Boston vs. Allston seems pretty clear, but what about "Italy" vs "Florence, Italy"?
We could set some goals as part of this process: we can define what levels of size/activity/geography would need to be present before endorsed group subdivision is allowed, and a unit of geography (city/town, probably) that it doesn't make sense to go below. However, this gets a lot trickier once we explicitly allow affinity/interest groupings. There are lots and lots of ways to nest interests.
Ultimately I think it may be impossible to impose before-the-fact moderation that works here. I think our best bet may be to:
A) Discourage non-distinct groups by doing a search for similar/nearby groups on submission.
B) Make it easier for groups to merge harmoniously.
C) Create a culture that's about having big inclusive robust groups.
D) Sink ghosts and flag inappropriates.
And then discontinue our policy of capricious human moderation, and embrace this whole crazy internet thing of letting 1000 flowers bloom.
https://pantheon.io | http://www.chapterthree.com | https://www.outlandishjosh.com
For A) we really need geo
For A) we really need geo integration which is a goal anyway.
josh's list looks pretty good to me.
Is there some way we can list criteria for success? After 6-12 months, how can we evaluate the site and know if we have made a good decision?
Group hierarchies?
One way of helping build groups might be to allow for group hierarchies. There's an og_hierarchy module (though it has no releases, not even a dev release) but maybe someone with better knowledge of OG might have another idea how to architect it. The core idea would be to allow for larger groups to be broken into smaller sub-groups if needed, e.g. the Florida groups is started to need other groups for more geographically-close regions, i.e. Miami, Tampa, Orlando, Tallahassee, etc, rather than overwhelming all members of the larger group with discussions that very much only relevant to a smaller portion.
Well, group hierarchy needs
Well, group hierarchy needs some defintion. Are they hierarchical just in the sense of a groups directory? Or do we mean that content posted in the parent is also posted to the children. Or vice versa. membership has similar up/down issues. Group hierarchy has more thought in the D7 version of OG. I'd recommend waiting for that unless we are just talking about the directory here.
/me in IRC '"yep agreed that
/me in IRC '"yep agreed that the more modern way to scale this is to let everybody in and let the good stuff bubble up/weed out the stale ones."'
(thanks greggles for pointing out this discussion)
also, I found this because I just denied the 'dogs' groups and felt bad immediately afterwards. Sorry. :-\
Other thoughts:
C) Create a culture that's about having big inclusive robust groups.
Get this down to a compelling paragraph or three and it might even get read. Translate these into guidelines/tips/behavior for a pleasant stay on gdo.
And this is leading then for how we approach:
A) Discourage non-distinct groups by doing a search for similar/nearby groups on submission. (a.k.a. "get people to the cool stuff, quick")
We should obsess heavily over this sign-up / group advisor experience. Make people find their topics of interest smoothly and have much productive fun as active members first:
Members work in tags, managers maintain bigger pictures in groups?
Groups providing the "social glue" (ugh, I know) around focussed bundles of tags? Tracking topics/tags is a lower threshold for newbies to start exploring no?
B) Make it easier for groups to merge harmoniously.
D) Sink & Flag
and re: hierarchy across groups
I'm again curious to know we could do with tagging across groups. Conceptually: filters across the whole pre-group mess to zoom in on topics/tags you like, expose groups as the more robust topical containers later.
yep, rambling…
--
still, from the initial wiki post:
Allow easier curation of topics into/out of groups
Promote uniqueness in group submission
both need more ideas I think.
Yeah, there's a rewrite of the wiki itself in here, but first dump goes here for now.
Action Plan
I'm not sure that adding any further comments to this thread is going to result in a clear action plan considering the length and age of this topic. What area's of this issue need further refinement? As moshe commented,
It's been nearly 2 years with no action on this topic. Relative to the mentioned Drupal Parents group, I think that some line needs to drawn between Drupal and how it affects our lives, rather than so much laser focus on who uses it. My contributions to the community certainly come at the expense of my family and I would welcome a place to discuss these challenges (among others) with like minded people.
My understanding is that g.d.o is a place to discuss and overcome challenges that our involvement or use of Drupal raises. If this is not the case, please correct me. To that end, I feel that some consideration needs to be paid to an auto-approval process that favors activity and energy in the community over specific overlap or oversight.
Honestly, what is the harm in having two similar groups if the content is different and people seem to be engaged? In other words, is the purpose of g.d.o to collect content, or promote usage of drupal through community gatherings. If promotion is the main goal, then groups should be allowed to rise and fall, split and merge organically. If the goal is collection of content, then the current efforts to curate members and content seems to be working just fine.
Chris.
greggles asked me to
greggles asked me to contribute to this thread. I've added to the wiki a link to StackExchange's page that describes how they approve new sites. They have a number of documented steps that they call phases:
From what I can tell, this is pretty much how some groups here on groups.drupal.org already operate and become approved. Once groups are created and it's put in the moderation queue, the groups' creators / organizers often (but not always) do the following things:
Based on some of the above criteria (and likely other criteria that isn't documented anywhere that I can see), groups are then approved by a groups.drupal.org site admin.
Of course, the main difference is that groups.drupal.org doesn't appear to have very good documentation of how groups are approved and StackExchange does appear to have that documentation.
The only documentation I found isI found a discussion at http://groups.drupal.org/node/339, which was updated with:edit: The official guidelines are, of course, in the groups.drupal.org group at http://groups.drupal.org/node/20724
Lights, camera, ...
Indeed, let's take some action. I made an issue of the first item in the list, to demonstrate how we can start taking action. I encourage others to do the same for the other items and focus on implementation.
Open it up
Nearly 2 years after my previous comment, I still believe in a much more open policy for groups. One thing that has become quite apparent to me in the intervening 23 months is that the more "we" (moderators, webmasters) try to meddle in the process, the more we risk getting mired in politics, and inflaming situations.
To me the main barrier is not technical. It's resistance to letting go, resistance to let any possible duplication happen. It's embedded in Drupal culture. Witness the dustups surrounding proposed modules that overlap existing solutions. We have a collective history of frowning on things (especially those brought in by new people) that upset the status quo. Some of that is healthy, an extension of collective self-preservation.
We should be an enabling community. We want it to be easy to get engaged. Easy to organize. Easy to contribute. Easy to participate. Those goals are not served by telling people, "No, you can't organize yourselves, you're too close to those other folks so you have to let them organize you." Some people are happy to join existing tribes. Others form their own tribes. New tribes split off. Existing tribes merge together. What has happened is that moderators have been placed into the role of policing conflicts, when (I feel) we should be working to enable and empower people to self-organize.
Proposal
Immediately adopt a more open groups approval policy, and let the needs that brings drive interest in building tools to better manage the process. A good plan today beats a perfect plan tomorrow.
Not in this proposal
Making this policy change contingent upon development of new technical tools to make g.d.o better (which is a terribly valuable need and goal, but really should be a separate matter).
Thoughts?
PINGV | Strategy • Design • Drupal Development
I agree we should be enabling
I agree we should be enabling community to engage. But I'm afraid that duplication (or overlaps) of groups has the opposite effect and in itself creates a barrier that makes it difficult, if not impossible, for new users to find either information or meetups.
I feel another approach is the organization or division of groups ... make use of taxonomy. For example, in the Los Angeles group we make extensive use of group taxonomy. This has the benefit of allowing people in the region to more easily find what they want within the group. Looking for a tribe in Los Angeles? Just go to the events page http://groups.drupal.org/la/events -- you'll quickly find tribes on the Westside, Long Beach, Downtown, Valley, plus tribes that specialize in topics. Moreso, these tribes are "led" by different people within the group.
The real problems don't seem to be lack of groups, but instead the lack of tools for organizers (and group admins) in the group to make (better) use of taxonomy. As it stands the current tools are pretty limiting.
So, in short I agree with the current policy that says "We want fewer big groups given a choice." I feel 'fewer' is both clearer and easier for new people -- which is enabling -- and making use of tools such as taxonomy & views & panels allows people to easily and organially subdivide within groups. Just post an event or a discusssion ... and tag it.
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
hmm, it occurs to me that the
hmm, it occurs to me that the best option is to simply open it up to the community to approve/deny groups -- rather than moderators.
obviously some questions on how to implement ... but it seems it could be the most transparent way to operate and I suspect would eliminate a certain amount of work (& politics) once implemented.
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
"how to implement it" is
"how to implement it" is exactly why this has been blocked.
See my proposal below which is similar, but little work.
Yes, it's frustrating not to
Yes, it's frustrating not to have better tools in place for organic moderation, but also frustrating to see users post 100% duplicate groups. Did they not even see the search box?
Here's an idea that's requires little to no development:
let's allow users to create group PROPOSALS instead of groups themselves.
proposals could be a node type and have several fields that would give the opportunity for deeper insight into the motivation than a group description provides. Also, proposals could receive comments and maybe up/down votes?
Then, the role of moderator would be just to transform any coherent proposal into a new group with appropriate ownership, rather than having a private back and forth.
This is probably a good idea
This is probably a good idea (one of the points discussed so far is that moderation is currently a behind the scenes task and we should make it more open and transparent, I agree with that). But would this proposal help this current problem? We'd have the downtown people saying they need the group approved and others saying it doesn't make sense. Then what?
Is this proposal meant to solve this problem or just be an easy-win related to the overall process?
knaddison blog | Morris Animal Foundation
Positive wins
My feeling is go with the positive. If the pro-group people have good, solid reasons for doing it then that should outweigh the nay-sayers.
I used to be very anti-dupe and still am against unnecessary duplication but I've softened my stance and realized that sometimes the harm of duplication is outweighed by the problems caused by preventing the dupe. We can't force people to work together. If we insist they not form a group that we consider duplicate and they really want it, there are plenty of other sites out there that will host them and that will splinter the community more than a duplicate group will.
And the losers?
After that we'd have non-downtown people saying the group shouldn't have been approved, the reasons weren't good and solid, and downtown people saying it was the right decision. Then what?
Whatever decision we actually make, we'll be making someone feel like GDO is hurting their local community, which seems like a problem. I'd like to focus on changing the process for making this decision so it's less subjective and less risky. We can make it less subjective by collecting some data we could use to assess group health, e.g. group activity. And we can make it less risky by improving the tools for reversing these decisions, e.g. group merges.
So?
Can't stop people from griping but I don't think that should affect the decision.
In "real life" if several members of an existing club decide they want to strike out on their own for whatever reason, the existing club has no right to tell them they aren't allowed to. Why should it be different here? As long as there are enough people wanting to split off so that the new group is actively used, why should the people of the old group get to tell them they can't?
In real life it depends on
In real life it depends on the type of club and what rules apply. Which is also why I said what's missing in order for us all to find agreement are some guiding principles that we can point to for clarity in decision making.
As it stands we're in a state of anarchy. and in anarchy, alliances count more than ideas (as Doug illustrated re: drupal4design).
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
I think we're essentially in
I think we're essentially in agreement ... that is until we disagree. :-) I'm kidding, but I mean @greggles brings up a good point about how to handle when people disagree on particulars. I assume that's where voting comes into play in your proposal... but how so? (part of "how its implemented" -- above). I feel, ultimately we need guiding principles. Which, in a round about way, is how I take what @christefano is driving at with StackExchange's approval process.
If we can agree on the purpose of g.d.o., then it seems we should be able to establish some guiding principles. (Is it as simple as the gdo homepage?). Which can ultimately lead us to approval processes.
To me, lack of clear guiding principles is the crux of this thread.
If the purpose of g.d.o. is to help people connect and share ideas, then to me its counter-productive to splinter similar interests into separate groups. By allowing this, the situation of multiple "same groups" (and leaving the "community to sort it out") creates situations where people never find "the other group" -- how would they know to search for another group? That's a disservice and confusing to users of gdo, and the result of not having principles that make it clear for moderators (or community) to decide.
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
ok, well I agree that having
ok, well I agree that having some clear guidelines would help in terms of disagreements.
Also, by having an open process the members or admins of existing groups could comment on whether there is overlap or need for a new group.
As will issues on d.o, groups that are controversial might take a long time or never reach consensus. However, I think it would let us avoid relying on a small group of moderators to do 100% of the review.
I'd also imagine text fields where the proposer explains who they searched for duplicates and why the proposed group would not duplicate an existing group. Requiring such an exercise to be clearly documented would avoid 50% of the problems I think.
ack! ok,,, seems I should
ack! ok,,, seems I should have re-re-read this thread. much of my post is a rehashing many of the sentiments above. so in summary, I'm:
+1 for promoting culture that supports big robust groups
+1 for discourage non-unique groups
+1 for merging harmoniously
+1 sink & flag ghost groups
+1 transparency
-1 open it up ... and let community sort it out. because this creates a dis-service to usability and especially new users to find useful information. I like the premise -- but i feel the problems it creates are even more divisive for community.
+1 to this is a bikeshed
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
Moving forward with this
We have some consensus around the idea of doing proposal reviews in public, so I added this to the list of transparency improvements, created an issue for it, and will start working on that issue. In the interest of doing this quickly before perfectly, I think we can just use the existing GDO issue queue for now. Since we haven't talked through changes the group creation side, I don't plan to change that just yet, only the proposal review process.
In a comment on the downtown
In a comment on the downtown LA thread, Michelle said:
This brings up another advantage of doing moderation in the issue queue, which I hadn't considered previously. We currently have no easy way to see how many of those 87 are intentionally postponed and how many just haven't been reviewed recently. As we move them to the issue queue and give them explicit statuses, that will be clearer as well as public.
Group Types
I have found there are at least 3 types of GDO groups.
1) They have meetings in a geographical location, a meeting room.
2) They are virtual groups, all activity is online at GDO.
3) They aggregate #1 above, reposting ONLY 'real meetings' in a greater region, or real meetings in neighboring groups. These pseudo groups have neither their own meetings, and have nothing in #2, no virtual discussions. They might discourage or prevent new group(s) forming inside those regions. We have several in California. Perhaps permitting this group type is a separate discussion?
I'm sure you might add more group types, or refine one of the above types into two or more types.
Point is, until you know what you are discussing, any changes will not be solutions, but aggravate the situation.
This suggests 'sets of criteria' for acceptance, depending on the group 'type.' Yes, it might be hard for many to categorize types of GDO groups.
Virtual groups, for discussions on a narrow, single topic, with no real meeting room, might be more quickly accepted, over a group that aggregates several thousand square miles (for example: Southern California Group - encompasses more square miles than any other group, and includes 10 or more GDO Groups - Could we have the USA group?)
The "type" of group should be identified, in order to allow other groups, similar in nature, to be proposed, that might appear to overlap, but do not. (What is "overlap?).
My post may raise more questions, and be unwanted, but it's a meaty topic.
Peter
LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE
There's an open issue
http://drupal.org/node/1551308 "Move new group proposal process to GDO issue queue"
I am +1 for this, but its execution take more than a little tinkering with d.o site configuration. How is the issue queue to be used? There's a process for Planet Drupal, a process for front page posts, we need one for g.d.o, or all we're doing is moving the broken system without addressing how it's broken.
My own feeling is that groups should be approved unless denial can be justified, rather than the other way around.
I also feel that this discussion here is way too buried for decent discussion and feedback. There is no way for people to know this discussion is happening unless they subscribe to this group and either visit the group regularly or happen to dig deep enough into tracker to actually see that something is happening here. The decisions here impact the broader community and any discussion should be as public as the moderations process itself.
PINGV | Strategy • Design • Drupal Development
I hope linking the issue from
I hope linking the issue from point 4 section c of the list of tasks at the top makes it clear there's no expectation it solves everything in this thread. We definitely need to continue the wider discussion. If there's anyone you think might be interested in this discussion who isn't already participating, don't hesitate to point them here. This is a public group, open to anyone who wants to participate.
New group policy updated - Let's focus on tools
The Guidelines for Forming New Drupal Groups has been updated to say that:
For more background see http://drupal.org/node/1485886#comment-5957738 .
I hope we can focus more automated tools on GDO that help community members to discover relevant, active groups and identify dormant, inactive ones.
sreynen and I did some brainstorming on additional tools, and we can add to the wiki/issue queue:
Automatically Display on group homepage
- Other nearby groups (geographical group)
- Suggested similar groups by name
- Similar by same members
- Groups people you follow have joined
- Automatically mark group as dormant with no activity in 6 weeks. Label that in the UI and give a negative search bias.
One other g.d.o usability feature (OT)
A bit OT, admittedly, but it would be great if I could get the default "my threads" kind of tracker visibility, too. Groups are balkanized discussions by design, but not being able to track the threads I actually participated in make it hard to keep up on things.
PINGV | Strategy • Design • Drupal Development
Here you go
http://groups.drupal.org/user/42/track
Tracking progress
What is the group consensus for updating the page with progress points? Some kind of marker? a big (DONE) tag? I feel that this issue is making excellent progress but that I would have an easier time understanding next steps if I knew what the status of the various line items was.
Chris.
Edit away
It's a wiki, so everyone is welcome to edit it. That said, I'm not aware of any of the open issues being completed, so I don' t know what could be accurately marked as done. Many of the steps don't even have issues yet, so creating issues is a simple next step anyone could take.