Change word "Manager" for something more accurate

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
DevElCuy's picture

Due to a hot discussion at: http://groups.drupal.org/node/69348 I noticed that the use of word "Manager" in local groups is generating so much confusion. Some people thinks that is a position of privilege and power, also as door open to abuse of power, etc. Also, when somebody creates a group: http://groups.drupal.org/node/add/og, there is any advice regarding local groups and the role that a "Manager" has.

Please may we define what exactly are the powers of a "Manager" and rethink about this word? can we use another more accurate?

Thanks in advance for your help.

Comments

Related issue

DevElCuy's picture

The second part of this issue is related to http://groups.drupal.org/node/42326, but I'm specifically asking to solve an issue of communication. It is sad to see all the misunderstanding that this word "Manager" generates, even more in non-english groups, taking to the point of generating conflicts.

--
[develCuy](http://steemit.com/@develcuy) on steemit

Being more clear

DevElCuy's picture

I'm talking about the text "Manager: [username]" in the top right block of all groups.

--
[develCuy](http://steemit.com/@develcuy) on steemit

Change to what?

Michelle's picture

I only speak English and "Manager" is a perfect word in English for the role. It's a person who manages the group so it makes sense. Like managers everywhere, they are in charge of their section. If there's a word you think would translate better, what is it?

Michelle

I actually think "organizer"

beeradb's picture

I actually think "organizer" is probably the best term in english for this. We typically refer to group 'leaders' as organizers rather than managers.

That being said, I'm not personally bothered by the manager label.

Depends...

Michelle's picture

For local user groups that makes sense. For something like "forum improvements" I don't think organizer is a good fit. Moderator might be better. Even for local user groups, the person who's organizing the (phyiscal) group may not be the same as the one managing the group page.

Michelle

list multiple instead of single?

greggles's picture

Aside from the label that we use, would it help to show all of the group admins instead of the one node owner?

I've done that on several sites and it makes more sense to me.

I think this change would be

beeradb's picture

I think this change would be nice. It better reflects the collaborative nature of running most local users groups, or really, most g.d.o groups as a whole.

Moderator(s)

DevElCuy's picture

What about using the label "Moderator(s)" and then list all the admins as suggested by @greggles?

IMHO owning a node does not automagically makes you lead of your group, and being owner of a node should not be a requisite to lead a group. Admins have power to guarantee the service of groups, so we empower them to help others, "service" is the key.

--
[develCuy](http://steemit.com/@develcuy) on steemit

---

apaderno's picture

To me, the word moderator means somebody with less powers than a manager; the alternative should be to use site maintainer, and admin, but that would create confusion between users who have particular permissions in a group, and users who have particular permissions in all g.d.o.

Support some change...

winston's picture

I don't like manager so much either.

Listing all admins might make that block to large in some cases, but since admins pretty much have the same abilities as manager it would make more sense.

Hmm, actually group admins with manager and admins listed comma delimited would work OK I think.

I don't mind the "Manager"

christefano's picture

I don't mind the "Manager" title at all but I'd really like to see all the group managers appear. Right now it shows the group node's author which is just strange in some groups that have multiple managers.

There's supposedly a distinction between "managers" and "admins" but I don't buy it.

---

apaderno's picture

AFAIK, there is a difference between an administrator, and a manager; a manager can approve more administrators, but an administrator cannot promote users to administrators.
At least that is what I get from some requests to change the manager of some groups; if there would not be any difference between administrator, and manager, then all the requests to change the manager would not make sense, when there are already administrators of a group.

I think it still makes sense to know who is the manager, as not all users are able to see who is the author of a group.

I don't think you are accurate

winston's picture

I'm an admin on a group (not manager) and I can promote other admins and remove admins.

Lo and behold

christefano's picture

Lo and behold, there's actually a Permissions and Content flow page that describes the different types of accounts and their permissions. I've added "group admins" to the list with my understanding of what group admins can do.

Thanks, however I had to add one

winston's picture

Once again I am a group admin (not manager) on a group and I can also send broadcast emails to all in the group.

Anyway I added that to the wiki.

So far the only thing it seems that is unique about the manager is
*appears as manager on the group home page
*cannot be removed as manager by other admins (so I as admin can promote or remove any other admin, but I can't remove the manager)

removed "manager" showing multiple "Organizers"

greggles's picture

I've used the fabulous drupal_alter('og_links') to remove the "Manager: " line and added in a block showing all the "Organizers" for a group.

What do folks think - any tweaks you suggest?

Sorry, I'm coming to this a little late ...

quid.oblitus's picture

Where can I go to see the change you've suggested just above. Thanks.

thanks for your awesome work!

christefano's picture

My only suggestion is to drop the "Organizers for this group" text since it's basically repeating what is already in the block title.

Alternatively, a brief description of what an organizer is or a link to the Permissions and Content flow page would be good. If possible, it would be excellent to have the type of account shown next to the person's name:

Group organizers
   This group has the following organizers:
  • moshe weitzman (site admin)
  • robertDouglass (site admin)

Excellent addition! Thank

nikkiana's picture

Excellent addition! Thank you!

Thank you Greg!!

DevElCuy's picture

You rock man!

--
[develCuy](http://steemit.com/@develcuy) on steemit

I think "group admin" would

pwolanin's picture

I think "group admin" would be the most accurate - these are the power to change the group page, alter taxonomy, etc.

I agree

Michelle's picture

Organizer is a funny name for it... What is Moshe organizing in this group?

Michelle

Configureable

DevElCuy's picture

I think that "Group organizers" is so amazing start point, and we need to discuss about more cases, because I see the title organizers more accurate for local communities, but for topic centric the word might be moderators, and for other cases in might be maintainer. What do you think?

--
[develCuy](http://steemit.com/@develcuy) on steemit

I'm okay with the word

christefano's picture

I'm okay with the word "organizer". That's the word that Meetup.com uses, too (for what it's worth).

Also, Moshe has stepped back a bit but he's still active in this group.

I think you misunderstood

Michelle's picture

I wasn't commenting on Moshe's activity level. I was commenting on the word. What is he, or the admin of any other non-LUG group organizing? Organizing content to put the spam in the spam bin? It just sounds weird. My point is that "organizer" is a fine name for the LUG group admins but makes little sense in a working group like this where the job is about spam control and making sure posts are on topic.

Michelle

Admin and moderators?

juan_g's picture

"Admin" and "moderators" seems to be the most standard naming on internet forums, and doesn't need explanation for most users. However other proposals here like "organizers", etc. seem also ok.

no perfect word, no configurable option

greggles's picture

I'm not sure we will ever find a perfect word. For me "manager" did feel wrong. That word has so many connotations and especially has a hierarchical one which is out of place on a more "doocracy" community like ours.

  • Coordinator
  • Organizer
  • Manager
  • Moderator
  • Admin

It seems these words are all tainted in some way and seem "perfect" to others...

I don't like the idea of making it configurable. That feels like a ux pain.

My thoughts

Michelle's picture

I think "Admin" or "Moderator" works best because they are more clearly about managing the group content on g.d.o. For groups that represent offline groups, "Coordinator", "Manager", and "Organizer" all imply a role beyond the g.d.o presence that may or may not be correct. A LUG could have a g.d.o group moderator that is a different person than the LUG's organizer. And, as I mentioned above, a non-LUG group may only have a g.d.o moderator and no organizer at all.

If you want to avoid any connotations of power to those entrusted with the care of the g.d.o group, how about "Caretaker"? I personally use "Gardener" on my site but that may be too much of a stretch in this multi lingual community.

Michelle

I like organizer

winston's picture

It is vague enough that it captures most use cases adequately.

Also, when a LUG has problems they are going to look to their leadership. gdo admin status is the easiest way to reflect that status and organizer is the least controversial word for this role.

Consider organizer in other use cases.

A group about preventing spam...
Organizer still works imo as the person can "organize" the home page, "organize" code or doc sprints, etc.

a group focused on a particular subgroup in the community...
Organizer still works

I guess I just don't see the problem with organizer.

I don't like organizer for

pwolanin's picture

I don't like organizer for the reason that you can also fill in "organizers" for every event node posted. So to me this is going to cause a confusion of terminology and context.

facilitator

jensimmons's picture

"Facilitator" is another option.

The word isn't as well known, but it does have the sense of someone who's doing work to make the group happen, and supporting the group, rather than someone who's "in charge of" the group.

http://en.wikipedia.org/wiki/Facilitator

Make it a drupal module

DevElCuy's picture

I think this problem belongs to other sites too, and would like to code a lightweight but so flexible module to help groups members identify the "staff around there". Drupal is all about collaboration, so all your feedback is welcome! please sent your mockups, ideas, prototypes any thing that you consider helpful. Even better, if you like, I can call you via skype to get your feedback and work together on moving this issue forward.

Hope to get news from you!

--
[develCuy](http://steemit.com/@develcuy) on steemit

groups.drupal.org was just

christefano's picture

groups.drupal.org was just moved out of the Drupal.org's infrastructure issue queue and to its own project at http://drupal.org/project/groupsdrupal.org

Hopefully the og_links_alter() code will be checked in or posted somewhere.

Reported

DevElCuy's picture

Thank you @christefano, just reported this topic as a feature request: http://drupal.org/node/850056

Brianstorming time ;)

--
[develCuy](http://steemit.com/@develcuy) on steemit

Make the block configurable/optional

jstoller's picture

I submitted an issue, Make "Group organizers" block configurable, which was postponed pending a discussion here. That issue was the result of several vigorous discussions in the LA Drupal community and appears to have broad support in Los Angeles.

This issue actually comes down to three interrelated issues, which each deserve some discussion.
1. "Group organizers" is not an accurate description of the role these admins play. This has caused a great deal of confusion and contention in our community and I expect we are not alone. There should be a saner default for this label.
2. Because you will never please every group with any one label, this label should be configurable on a per-group basis.
3. There are some compelling arguments suggesting that in some cases it would be better to remove the block all together, so there should be a way for group admins to disable this block within their group.

Why not "organizers"?

Quite simply, the term "Group organizers" does not fit the function of the people listed. The word "organizer" implies that the people listed are organizing the group's activities, but that is not necessarily the case. For instance, there are many people organizing monthly Drupal events throughout Los Angeles, but that has no relation to managing the GDO group. A far more appropriate term would be "Group moderators". That accurately describes the function of the people in that role, without implying any additional responsibilities they may or may not have to the group at large. Having an administrative role on GDO and having a leadership position in an off-line group are two very different things which should not be conflated. The only consistent thing you can say about any GDO group admin is that they have the authority to moderate discussions in their group, so that is the only thing their title should imply. Designations of additional responsibility or points of contact can be handled elsewhere.

Why make it configurable?

As I said, you will never make everybody happy with a single label. More importantly, I see no compelling reason not to make it configurable. In the issue queue, Greggles suggested that the group admins "...have specific permissions/responsibilities on g.d.o and I think it's important for usability we have a consistent title for them across the site." I respectfully disagree. If different groups call their admins moderators, organizers, leaders, managers, facilitators, coordinators, or even just admins, I think the users of those groups will be able to figure it out. The bigger danger is using a title for admins of a group that doesn't make sense within the context of that group. Calling the Los Angeles group admins "organizers" has caused no end of confusion and conflict.

Why make it optional?

Several people have pointed out that the mere existence of this block, what ever the title, implies that the people listed are "in charge" and have power that they may not actually have. They become de facto gatekeepers. This can place an undue burden on these admins, forcing them to deal with inquiries which they really aren't responsible for, but also an undue advantage, since any business inquiries are likely to be filtered through them. There is a strong sentiment in our group that if someone needs help, they should post a discussion in the group. That way it's open to the community to engage, including any admins, keeping everything fair and transparent. In the case of an event, you always have at least one organizer listed and, assuming they have contact forms turned on, they can be contacted directly. Or better yet, users can once again just post a comment. We even discussed the possibility of posting an email address on our group page that would forward inquiries to all admins simultaneously, while obscuring their identities. This would give people who feel they absolutely must contact an admin by email the ability to do so, without putting individual admins in the spotlight.

Basically it comes down to trusting all group administrators to act in the interest of the community. That includes providing appropriate introductions, instructions and points of contact for their group, in order to minimize confusion and improve the user experience. But we should allow them to configure their group in a way that makes sense within the context of the group, rather than a one-size-fits-all approach.

When it comes to implementing

christefano's picture

When it comes to implementing this, I don't know that it's absolutely necessary to roll out this functionality site-wide for all groups. Some groups (like the Knight Drupal Initiative group and, I believe, the GSoC group) have had custom features in the past.

My preference, though, is to have this kind of functionality in some of the other groups I manage (err... moderate), but the climate in Los Angeles has been near an emergency state and I'd like to know what our technical options are so that we can move forward. I'd be happy to host a code sprint at Droplabs to help get this code written and into the groupsdrupalorg project.

Aside from that bit about group-specific vs. site-wide functionality, I agree with everything else that jstoller is saying.

I was not convinced at first.

bvirtual's picture

I was not convinced at first. To remove the block. I heard arguments every which way, in small groups, 3-4 members, over the last six weeks. At LA's first structure meeting, to manage LA Drupal User Group's rapid growth, with 17 members attending, the last two hours, of a six hour meeting, GDO Organizer Block was all we talked about, as it was the simplest issue presented in the first 4 hours. This discussion initiated the process of finding replacement volunteer members for that block.

All 17 members wanted to know more about the 'duties' expected of a person listed there. They were surprised at how limited the "powers" were. Many questions were asked about these powers, until they were understood. The surprise at the past choices for this block title was expressed by all. Brainstorming alternatives resulted in no agreement. I doubt you have not heard this before: Any title will be inaccurate, prone to misunderstanding, more so as Drupal User Groups grow in size and complexity.

While I posted for individual member title - now, I'd like to see this block change, more along the lines of Jeremy's and Christefano's posts.

The consensus of LA members appears to be, ask what technically can be done, so we can rehash the issue again among the LA members. Thus, to refine the LA recommendation. There is a strong opinion, LA has more pressing issues. Most want to see a quick solution. Remove it, or make the title definable by the User Group, are the two current, popular, quick solutions. Both solutions have subscribers, and detractors. Leaving it alone... has no voices asking for that.

I know our member, Benno, wants to host monthly code sprints in his new meeting facility. I'll be there.

Pete

Peter

LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE

Optional + Configurable

DevElCuy's picture

I like the idea of enabling this feature on demand to the groups that are enough big and strong. Not every local community is an organization, and not every organizational community is structured the same way. For those that need delegation and custom titles/positions this feature could be of so much help. Is just like modules are maintained, there are a bunch of permissions that the owner can delegate to specific users, if we add a delegation permission and a custom title then we are done. Of course we need more granularity of permission, but lets start with the most common and we can ask for more in the future.

The question is: Do we want to delegate permissions? or just set titles?

This feature involves more complexity but we have to start somewhere :)

--
[develCuy](http://steemit.com/@develcuy) on steemit

At this point my big concern

jstoller's picture

At this point my big concern is allowing group admins to configure the visibility and title of the admin block in their group. This would be an excellent first step and I expect would not be too terribly difficult to implement. Restricting this feature to specific groups that are deemed to need it, seems like an unnecessary layer of added complexity to me. Myself, I would happily trust any group admin to determine the best course of action for their group when in comes to customizing this block. However, if that is the only way this will be accepted by the powers that be, then so be it. I just know that, as silly as it may sound, the current "group organizers" block is having a detrimental effect on the Los Angeles Drupal community, so I would like to see it go away as soon as possible.

@develCuy: Are you taking about custom titles for individual admins in the group? If I understand what you're suggesting, you think we should have different roles, or levels of permission, which could be assigned to different administrators within a single group. So some admins might only be able to moderate content, but not redesign the page. Is that correct? If so, it sounds like an interesting idea, but I think that is a whole different conversation.

DrupalCampLA BoF this weekend - more after that

bvirtual's picture

LADrupal should provide an example, like requested, but if our group can not agree, then it turns into several examples. I suspect the example of choice will be to make it go away. I am going to requested of the LA group to provide feedback to my examples. It will take some time.

In the meantime, my vote is for turning it off.

My vision is more of a self help block, where LA or any user group, can define the content in the "Contact Us" block. Large user groups have more than one point of contact based upon purpose. I'm not sure I can get LA members to agree to volunteer for contact roles, even if they currently are doing the job. That is, the current listing forces any listed member to be the point of contact, in all things.

I'm almost convinced myself the idea of forcing them to post is a good one, except for the fact, some contacts should be private, not public. Raffle prize donations, sponsor contacts, venue offers, in order to 'save face' if the offer can not be successful negotiated. So, I want a block, but it can not point to members without a "purpose" for contacting that member.

If we have 3 people who can handle venue offers, then how does that get listed? 3 identical titles with different member names?

I'd much rather have role_aliases@ladrupal.org be the link, and not a member. That way all 3 members handling venues will get the same email. I've done this before in other user groups. 1 of the 3 is the primary responder for the easy stuff. Valuable stuff results in the 3 members phone calling each other with great excitement and they choose the right member to reply.

And I can expand this logic, but I suspect we know where it goes. Getting the current block to disappear, and having a custom block...

BUT... First, LA Group must do it's homework for a custom block solution. I would not want GDO to go to custom titles just for LA, when that solution will not fit LA either.

And why not the option to have "no" organizers, and when that happens, the block disappears? That makes sense only if a GDO group can exist without an organizer to show in that block. I've got to look at the code. I went looking for it at www.drupal.org/project/groupsdrupalorg ... no download?

http://2011.drupalcampla.com is this weekend, and I know a BoF is in the works to talk about this. After this BoF, I expect the discussion here to get definitive for LA. I'll see if we have volunteers to serve in roles, and if the 'titles' will fit. Otherwise, this block ought to have a display:none option, imho. I'm going to keep trying to get volunteers to provide LA's large user group with a professional list of contact points. A visual aid will be produced.

Pete

Peter

LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE

I've got to look at the code.

greggles's picture

I've got to look at the code. I went looking for it at www.drupal.org/project/groupsdrupalorg ... no download?

There's no release as a tarball because nobody should be using that module on other sites so it makes no sense to have it easy to download.

If you click the "version control" tab it will tell you how to download via git.

Lots of things are technically possible. The idea of having multiple contacts is currently possible right now via the group mission and og_panels custom blocks which would require zero extra work.

I think it would be good to

mike stewart's picture

I think it would be good to have the ability to remove the organizer block in groups, especially for regional groups that are significantly different than topical groups. Regional groups don't really have "leaders" -- they are organic by nature and recent activity is always more important than past.

I would like to know more about why others feel this would not be a good thing? For instance, gdo doesn't list a webmasters block -- and gdo still functions ok.

--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }

gdo actually does list

greggles's picture

gdo actually does list webmasters. From the "about" link in the footer you get to http://groups.drupal.org/about which lists at least 3 webmasters. The Policies section of that page also links to the moderators and lists everyone on this site with advanced roles.

I mentioned why I'd like to keep this above. The "group organizers" do have extra responsibilities on this site and, especially for a consistent experience between groups, I think it's important for people in need of help to be able to find the organizers.

I feel webmasters,

mike stewart's picture

I feel webmasters, moderators, and group admins are analogous in their roles on GDO. and when I mentioned there wasn't a webmasters/moderator block, that's exactly what I meant. I hoping to illustrate GDO actually lacks consistency in this way... and even moreso (as a group admin, I have) the ability to make it more inconsistent, I can remove the sidebar in its entirety!

So, in what way does having the block solve the things you list? I guess I'm not getting it? I might even point to the fact issues keep arising about this block as proof it means different things to different people -- and maybe the takeaway is if you aren't ever going to be able to please everyone, then allow it to be configurable and let each group decide.

Lastly, why is it important for people to be able to find the organizers? I mean it sounds kind of silly to ask, I know, but really, why? To me, a discussion posted to the group serves the same purpose, plus its a single/simpler workflow as far as newbies go. and most importantly, its totally transparent (with accountability built right in as a normal discussion).

--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }

Privacy is not available with a post

bvirtual's picture

Having only a public post to communicate 'issues' that would make the group look bad, means having a private way to talk to the responsible webmaster, to correct typos. I could think of another 5 reasons to have a private way to communicate to a webmaster or organizer. A dozen more if you press me on it. Even 2 dozen.

Peter

LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE

It's true that not all

christefano's picture

It's true that not all regional groups have leaders, but not all regional groups are organic by nature. Nosiree. Many groups are run by a small number of strong personalities (if not one individual) and they should generally be able to run the group any way they want.

For instance, gdo doesn't list a webmasters block -- and gdo still functions ok.

Sorry, but that's comparing apples to oranges. We're talking about the IA of individual groups, not the organizational structure of groups.drupal.org itself. Besides, everyone knows who runs groups.drupal.org (or they can easily find out) and the issue we're debating here is what would happen if the Organizers block would be removed.

I believe removing it would make things worse, especially to a group's transparency, the accountability of individual's actions, and what it would do to Drupal newcomers' confidence and ability to find point people.

$gdo_admin != $point_person

jstoller's picture

Christefano, that's part of the problem Mike is describing and I am 100% behind him on this. GDO group admins are not point people. At least not in the way they are used as point people. Nor should they be. Their only responsibility is toward moderating the online discussions within their group. If the sole existence of your group lies within the confines of those GDO discussions, then so be it. But anything that implies they have any power over/responsibility to a larger Group (like a regional group), is just inaccurate and confusing. It does a disservice to the people named in that list and the people who aren't, not to mention the poor, hapless newcomers.

If users have questions about a specific event, then they should be contacting the organizers of that event, which are prominently posted within the event listing. Even a newcomer can figure that one out. If users have questions about the group as a whole, then they should post those questions to the group as a whole. We don't need gatekeepers. Having them reduces "a group's transparency, the accountability of individual's actions," in my opinion.

If a group needs to have a point of email contact for moderators and doesn't want to display the "Organizers" block, then they can create an email alias that forwards to everyone responsible for moderation. This can be posted in the group's mission and/or a custom block. Problem solved.

Well said, and I agree with you

christefano's picture

Well said, and I agree with you. When I say that removing it would make things worse, I mean that removing it without having an alternative ready to go will negatively affect the group's transparency, the confidence of newcomers, etc. Thanks for spotting that and calling me out on it.

Yes, creating a "Contact with the community" pane that can go on a group's OG Panel pages is easy. Those would be visible only on a group's main OG Panel pages, though, and not on the posts within the group. It's not a complete solution, in my opinion, but it would be an incremental improvement.

For the LA Drupal group, would you be up for writing a "Contact with the community" description for the various OG Panel pages? We can talk at a meetup or in the LA Drupal group about that if you want so we can keep that stuff out of this thread.

Let's leave the LA specific

jstoller's picture

Let's leave the LA specific stuff for conversations elsewhere. We should keep this conversation to more general issues, of which LA is one use case.

bvirtual's picture

I sure hope what GDO volunteer efforts are done, based upon the consensus this thread reaches, does solve LA's concerns, and can be used by other, similar Drupal User Groups, who need to change/remove the Organizer block, due to it's extremely limited role that it plays in 'a' User Group.

Given, OG Panels gives us a generalized solution to list one or more 'new blocks' with custom block titles, and member titles (and/or roles), or what ever an User Group needs might be, now or in the future (is that true?), then...

I think the consensus must be an 'option' to remove the Organizer block, fully complementing the OG Panel approach to supplying "custom points of User Group contacts," based upon being: the MC, the President, the founder or one of the co-founders, provide a life time of "emeritus" status for individuals who have exceeded all volunteer level expectations, list of individual meeting contact points (Burbank, Pasadena, Downtown, Culver City, Santa Clarita, Long Beach, Hollywood, etc, etc) and even nearby User Groups (Inland Empire, Orange County), etc, etc, where links can be to member contact page, Current Event Page for that meeting, or linking to any page of concern.
Then, I'd say a rational solution has been put before those interested, but not to all parties. That is, the rest of the LA 'active' volunteers interested should have a few weeks to learn of this thread, read it, and post their +1, or provided feedback to a two part solution, as follows:

1) LA Organizer Block will be removed, with future option to restore it, which does not need to be a checkbox, but could be requested of a GDO webmaster (what ever is less effort).

2) LA's GDO webmasters (we hope to have 5 more soon) can create a OG Panel block, or two or three, as visual aids. LA can change this blocks when needed, without bothering GDO webmasters.

Is this too early in the thread to put forward the above strawman solution for review by LA membership, give it 4 weeks (through our next 30 days of 5 meetings)?

The roadmap would have some consensus posting, +1's, and comments, with an explicit request to GDO webmasters, with GDO webmasters agreement the consensus solution is within their ability and desire and volunteer level of effort to implement. GDO webmasters would schedule their implementation over the next 1-3 months (I'm not going to push GDO volunteers hard on this - but others might).

Upon completion of the GDO webmasters installing the "remove" feature, LA membership "will" have alternative blocks already displaying. Our effort to rev up LADrupal.org might include defining the contents of this new GDO block(s), as the same information will have to display at our website as well.

That leaves the question of how to tell other user groups this option now exists. I raise this point, as the exact 'remove' method has not been decided, and this "advertising" might influence GDO webmaster's druthers for solution direction. I suggest GDO webmasters might voice their opinion if this option to remove the block is available to all User Groups, just to the LA Group, not advertised to any User Group, or just advertised by a closing post on this Discussion, or ____ (you fill in the blank), then that would complete the roadmap, and close the roadmap definition.

Peter

LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE

Consistency? What consistency?

jstoller's picture

As a UX designer, I tend to like consistency, but in this case I think that consistency is hurting usability more than it's helping.

As I understand it, the purpose of this website is to support Drupal communities, whether they're regional groups, subject groups, or working groups. It also must deal with big groups, small groups and everything in between. I think the discussion to date makes it abundantly clear that these different groups often have very different needs. I for one trust that each group's admins ultimately want to provide the best user experience they can for their members (new and old). I also assume that they know far better than I what would provide that good user experience for the specific audience they serve.

So, I'd like to ask what problems people are trying to solve with this consistency? As it is, when I view different groups on the site, they look pretty different from one another. If we were to implement the features as I proposed and every group could hide or customize their admin block, what exactly do you think the negative impact of this change would be, both on GDO as a website and on its webmasters?

I disagree with the

greggles's picture

I disagree with the perspectives here, but am willing to be flexible since I seem to be in the minority.

  • Someone needs to write code to make this block optional per group in a way that will strongly suggest alternate contact information needs to be provided. I'm thinking it would be a box for "alternate contact info" on the group node and if that box is populated then the group organizer list will not show and instead the alternate contact info will show.
  • Someone needs to write code to make the title configurable
  • Once those are done and reviewed, we need guidelines added to the permissions and content flow suggesting how/why to use this

Starting the dev process is design the solution

bvirtual's picture

That some one will be a group of LA members, no doubt. Designing the requirements is next. Greggles has outlined an acceptable solution he can get behind. It's a good starting point. Meeting all these requirements is the first issue to review. My first concerns are:

  1. "... if that box is populated then the group organizer list will not show" strikes me as a new feature, and it seems like a desirable default condition, unless a group wants both boxes to show. However, that's looking at 'my' solution that the "alternative contact info" box is fully optional.

    The "new" feature I see is, if the "standard" Organizer Block is not present, then the 'alt info' will not be optional, and the alt info box must not be empty.

    Thus,keeping a way to do a "private" contact available for sensitive issues (want to donate $10,000), or issues without a compelling reason to be public (more noise than signal).

    It also strikes me that making the existing Organizer Block have a custom title and custom fields is the identical solution. And might be less work?

    This new feature might bear discussion. Anyone?

  2. Guidelines will be authored. I can see this will be a different discussion. I think using the LA organizer's mailing list might be better for this design, as it's more private, but still public.
    1. Be prepared for several paragraphs.
      1. A list of suggested "roles"
      2. How to link the titles (to user profiles, or 'role' email addresses for routing to 2 or more emails)
      3. Include the name of the person(s) being contacted, perhaps even a second link to their profile. When to use such a construct.
    2. Currently, which of the two below appear in the Organizer block currently: Group admins or Group managers? Yes, it is missing from the page. Group Managers I suspect. It's a wiki and I will add this fact, once I have it confirmed.

Below is somewhat jumping the gun...

I wanted to start faster, so thinking this block was defined in the groupsdrupalorg download, I read it all. Would we put overrides into this download as the 'best' way? I was hoping to make that decision myself, but I'm wondering how the Organizer block is made in the first place - read I'm just an authenticated user, and can not view OG Views Displays. I'm sure a Site Admin will export what we need to set up a Dev GDO.

Or is there an install profile available? As I did not find one, I got this drush dl list working, assuming the latest releases are running GDO (ah, sure... yes, I'm looking for the release list, so I can start coding sooner, not later.):

drush dl drupal-6.22
drush dl apachesolr
drush dl bakery-6.x-2.0-alpha2
drush dl date
drush dl diff
drush dl fasttoggle
drush dl image
drush dl markdown
drush dl modr8
drush dl mollom
drush dl notifications
drush dl og
drush dl og_panels
drush dl pathauto
drush dl radioactivity
drush dl signup
drush dl views

Peter

LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE

The current block is provided

greggles's picture

The current block is provided by a view. It is the og_members view, block_1 display. You should be able to use OG and views_embed_view to get a patch to groupsdrupalorg.module.

If you disagree with my perspective on some of the specification go for it and we'll see what others think.

How to set up GDO dev site instructions needed, please.

bvirtual's picture

Greggles,

There has been discussion here in LA, and I have done several examples, and Jeremy did a minimal example. We are ready to start some code changes. Missing is setting up a GDO like dev web site with the current view to modify, or see how it's done, and might be coded to have an optional override driven by a new admin tab or page.

So, the question is how does one go about setting up a GDO duplicate (minus userids and passwords)?

Rumor reached me of a scratch test site for groups.drupal.org, but not the URL or how to gain access...

Is there a web page that tells how to set up a GDO dev environment?

Export the view and attach it here? But more than the view export is needed, like admin pages to add the option to.

I understand our changes will be going into project groupsdrupalorg for the review of GDO webmasters, which may take time.

LA members will set up a dev site, with visual aid examples on how the admin configuration for the Alt GDO Org Block. Along with the requested descriptive manual text stating how it could be used by other GDO groups.

Peter

LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE

Now exported all content

greggles's picture

Now exported all content types and views:

http://drupal.org/node/1265716

That should
1. Let you install that on a site to get functionality similar to this site
2. Provide a place to make your patch

like admin pages to add the option to.

If you mean "group organizer" pages then that seems fine. But if you really meant "admin" I'd like to hear more about what you think needs to be managed by admins.

Thanks Greggles

bvirtual's picture

I got the export and wow. I have my work cut out for me in creating a GDO dev environment. The drush list I posted was way incomplete. The bar is quite high for creating a dev GDO.

Finding the needed dependencies, like calendar_ical? Google lead me to drupalcontrib.org and to the module calendar. Seems obvious. So does the ical module. SolrPHPClient, what fun, with Java 5, too, which is not on my web host, so I will scp everything to my office computer. Enabling module after module. Or not try for a full GDO dev environment, but get enough working for just the Alt Org Block development.

I was surprised when the Modules page no longer displayed the full list of dependencies needed for the groupsorg module you provided. It now only lists

groups.drupal.org          Site specific bric a brac
misc                       Depends on: Organic groups (enabled)

where even the description is truncated. Par the course for a newly created snapshot.

Will I need the other 3 snapshots installed first? Or was this one 'complete?' I glanced at them, so small, and quite different compared to your snap with Features.

I'm left wondering if older versions of the modules are needed, and not the most current. The Available Updates page (or 'drush up' stdout) and certainly the Modules page is a must have, and would ease setting up GDO Dev.

Creating GDO dev will have to wait until this weekend. What I've done to date has been fun. And "similar" will have to be what I settle for. Hmm, hazy recall of reading a thread 2+ years ago about GDO not being fun to develop. You have your work cut out for you, Greggles. :-)

Re: Admin vs Group Organizer pages - I'm not seeped in GDO terminology, ... yet. My bad.

Peter

LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE

I don't know what you mean

greggles's picture

I don't know what you mean about the snapshots. We might have better luck discussing some of this in irc #drupal-groups

You should definitely pull the code from git so you are getting the latest verison.

You can probably just remove the dependency on solr from the .info file - I doubt you really need it.

bvirtual's picture

IRC listed you as away, so I'm posting.

Ok, snapshot is a little known link found in a hard to find page. ;-)

http://drupalcode.org/project/groupsdrupalorg.git/snapshot/refs/heads/6....
http://drupalcode.org/project/groupsdrupalorg.git/tree/refs/heads/6.x-1.x

So, to be sure, I did a git (assuming a few things for the project name and branch - hey, I'm still learning my way around the new D7 git way of doing things, with all these new 3rd level domain names.)

git clone --branch 6.x-1.x http://git.drupal.org/project/groupsdrupalorg.git

then a diff:

diff -r groupsdrupalorg ../modules/custom/groupsorg

Only in groupsdrupalorg: .git

So, I'm safe, no differences. [I've been tarballing for 30+ years ... does drush git?]

BTW, I noticed "groupsorg.install: No newline at end of file" - what's Best Practice for this?

Also, the module machine name is without the middle 'drupal', but the folder name has it.

[messenger plays dead, hoping not to be killed.]

I'm stilling to finish the OG install. What node types should I set to act as groups? I had hoped the new module supplied by greggles would include these settings in the Feature. Hmm, maybe it did. [goes hunting in folder tree]

I'm wondering if my current effort to create a GDO dev environment would be useful to new members? I'm posting details for my LA colleagues who might want their own GDO dev. I have tarball of webroot and mysqldump to distribute, if asked.

Noticing that webroot subfolder file /gdo/gdo/sites/default/settings.php having a base_url of gdo/gdo does not set all links to have this base. Bummer. More details if I find the missing two links again.


Just tried drush, and while all the pages worked fine, the second invocation of drush provided me with some amusement, erh, I mean, concern.

WD php: include_once(groupsorg2.features.inc): failed to open stream: No such file or directory in
sites/all/modules/custom/groupsorg/groupsorg.module on line 3.

Yes, that include really is there:

grep groupsorg2.features.inc *

groupsorg.module:include_once('groupsorg2.features.inc');

ah, geeh, maybe remove the 2... no. Okay 'touch groupsorg2.features.inc' created an empty file, and got rid of the error.

[goes looking for a rock to hide under while greggles looks into this]

Would I post such issues at http://drupal.org/project/issues/groupsdrupalorg? Or I thought I saw another issue queue, much shorter, but not finding it now.


FYI - greggles skip the reset

What I have enabled, for others treading down this path (wondering if GDO needs to have older versions, not the most recent stable - to be found out later)

Drupal core 6.22
Calendar 6.x-2.4
Chaos tool suite (ctools) 6.x-1.8
Content Construction Kit (CCK) 6.x-2.9
Date 6.x-2.7
Diff 6.x-2.3
Features 6.x-1.1
Image 6.x-1.1
Link 6.x-2.9
Markdown filter 6.x-1.2
OG Panels 6.x-2.0
Organic groups 6.x-2.1
Organic groups access control 6.x-2.1
Panels 6.x-3.9
Pathauto 6.x-1.5
Site Network 6.x-1.01
Token 6.x-1.16
Views 6.x-2.12
Views Bulk Operations (VBO) 6.x-1.10
Voting API 6.x-2.3

what I just disabled to get rid of an error message when saving Modules or running cron. ApacheSolr allowed me to enable it's modules OG and Search before the ApacheSolr framework module.

Apache Solr Organic Groups Integration 6.x-2.x-dev (2011-Feb-25)
Apache Solr Search Integration 6.x-1.5

Disabling was done with drush, the Search first, otherwise the error got in the way.

I've downloaded a lot of other modules, and did not enabled them, as they were not obviously needed to get the bulk of GDO running. They will be enabled as needed.

Peter

LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE

Thanks, greggles. This is one

christefano's picture

Thanks, greggles. This is one of the issues I've been meaning to look at and fortunately had time for today during Drupal Dev Day at Droplabs. I've opened a few issues at http://drupal.org/project/issues/groupsdrupalorg and will spend time on them again at the next Drupal Dev Day.

Ambassadors

mcfilms's picture

I would just like to reiterate my position (from another thread). I feel very strongly there needs to be at least one (call them what you like...) ambassador in the upper right corner of each groups page. My personal experience is that I may have never attended my first Drupal meeting had I not been able to easily reach out to someone in the group, communicate about the group via email, find a meeting and feel I "knew" someone upon going to the meeting.

I haven't heard a sufficiently good reason for disabling this block except that the semantics used to describe these ambassadors (or organizers) might lead to some small amount of confusion or hurt feelings. That's not a good enough reason to remove this point of contact.

Ambassador ... That's just what the LA User Group needs

bvirtual's picture

I like that title. It has few preconceived notions and actually could describe the desired function of initial contact point to grow the group's membership.

I agree with the 'requirement' of having the block, as well. I've always wanted it. But, I also want consensus of the LA membership, so I had to ask for feedback, to be sure our members get on the same page, and can get behind a code sprint to make this happen.

Also, I want something "bigger", something for future large groups to be able to use. I'll post a preliminary strawman block, and list what admin controls I see it having. People like visual aids to assist in the decision making process, and I want to see this concluded sooner.

Peter

Peter

LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE

I think the interface for

jstoller's picture

I think the interface for this could be very simple. Just a "Group contact block title" text field and a "Group contact block content" text area.

The "Group contact block title" field would have a sane default, but could be customized, if needed.

The "Group contact block content" field could default to a token that renders the standard admin list. That way admins have the option of using the list as is, using the list with additional text explanation, or completely replacing the list with their own content.

If you make these required fields, you can easily encourage the inclusion of some point of contact for the group, even if users aren't listed by name.

Personally I'm not sold on the use of "Ambassadors" for the LA group, but I don't want to get too much into that discussion in this forum. Needless to say, the system I'm proposing would allow for these people to be called Ambassadors, or Moderators, or the Welcome Committee, or stick with the current default. And you could use the default list, or make up your own list (with separate titles), or get rid of the list and just add some text. It would not allow for the block to be hidden all together, as we discussed, but you could alter the block enough that it was effectively hidden. For LA, I would suggest something like this...

Group Contacts

If you have questions about LA Drupal, we encourage you to post them to the group. You can also post comments on a specific event, or contact that event's organizer. If you have any problems with this group, please email moderators(at)ladrupal.org.

Welcome Committee I like even better ... leading to...

bvirtual's picture

Jeremy,

You got me thinking the strawman prototype I was planning was/is overly complex, and could be done within your suggested implementation. My idea was more rigorous, and did not permit the block to be used for other purposes.

My idea could be done within yours as a series of examples, of what is possible, to make a large group look large and lively and going strong. The latter is a primary concern. A marketing aspect of attracting new members to a growing successful user group. Not underselling the value of the group to potential new members.

Growing the Drupal community is a, if not the, single primary motivator behind my effort in this forum.

Examples could give a wide variety of titles to choose from, roles to list, contact methods, subtitles, and best serve growing the group larger by leveraging a list of contacts.

For our LA meetings, a potential speaker needs to know who to contact, and a group with many monthly meetings needs to better solicit speakers, so last minute announcements are replaced with 2-3 months of advance bookings, making the volunteer doing the meeting have less work to rush just before a meeting.

My vision is a large list of contact roles to ease the effort of our active volunteers and avoid early burn out. The easier it is for our 'leaders' to make meetings with great value happen, the happier these very same leaders will be.

Fact is, I can see your proposal with my examples as the first implementation done in GDO. Less effort, no complex design, coding, debugging, or testing. Quickly done. Then, let large groups actually use both, see what sticks. Any second GDO implementation would be market driven. A strategy using less volunteer time, and more prone to success.

Pete

Peter

LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE