[ug-discuss] Re: [osol-mktg] Community Consolidation -- Marketing & UGs

[Jim Grisanzio]

Bruno F. Souza wrote On 04/06/07 23:39,:

> Let me describe the way we "solved" that for UG on  
> java.net, this may be a good starting point for the UG community for  
> OpenSolaris.
> 
> - there is a JUGs Community: this is where JUG leaders join and  discuss 
> joint efforts. The JUGs Community has a few mailing lists  that are 
> targeted for JUG leaders to discuss things, and hosts very  few content 
> by itself. It is more like a discussion on how each  leader can make his 
> own group more effective by learning from others.


Cool. We basically have that structure here as well (or tried to, 
anyway). ug-discuss is the meta list for cross UG communication, and 
that's basically been the leaders or the most active people. Although I 
had originally imagined it as a many-to-many relationship where anyone 
in any user group can talk to anyone in any other user group, I can see 
now that it's probably better to focus it as more of a leader-to-leader 
relationship.


> - each JUG can request a project on java.net, that will go "under"  the 
> JUGs Community. The project hosts the JUG mailing lists, files,  etc. 
> Some JUGs even have _software_ projects, that are hosted as sub- 
> projects of their JUG. One important thing is that in java.net  project 
> requests are not a "community wide" thing. So, JUGs request  projects 
> for the JGs Community, and that gets approved by JUG  Community Leaders, 
> that are elected by the JUG Leaders. So, when a  JUG request a project, 
> it can be approved right away (it is actually  put under the incubator, 
> and when JUGs comply with a few  requirements, like creating a web page, 
> etc they are "graduated" to  become a project under the JUGs Community). 
> It does not need to go  trough any "community wide" approval or vote.


Interesting. Ok, so we can easily migrate to a system where individual 
UGs become projects (so they are not just pages/lists within the UG 
community) as per Stephen's suggestion, but our current project request 
process goes to the entire OpenSolaris Community on opensolaris-discuss 
for approvals, not just UG Community's ug-discuss list.

However, under Article 7.1 of the OpenSolaris Constitution, Community 
Groups are responsible for initiating and managing projects:

7.1. Purpose. In order to promote a diversity of activities within the 
OpenSolaris Community and to provide a means for self-governance within 
those activities, the OpenSolaris Community is held to be composed of 
Community Groups that are initiated by the OGB for the purpose of 
focused management and accomplishment of a given set of activities. 
Community Groups are, in turn, responsible for initiating and managing 
projects to accomplish those activities.

So, this is where where the User Group Community can assert its leadership.



> - The JUGs Community on java.net recognizes that JUGs may be part of  
> the community even if they don't ever request a project in it. So,  the 
> JUGs listing lists all JUGs that want to be listed, no matter  where 
> they host their members. And the JUGs Community is still the  place for 
> the JUG leaders to discuss, even when their JUGs don't  share the 
> java.net infrastructure. Some JUGs even don't trust Sun  enough to 
> request their members to register in java.net (since  java.net is a Sun 
> infrastructure). But they are part of the JUGs  Community nonetheless.


We have only run into this issue a couple of times. Not a big deal so 
far. But we do list groups that are not part of our infrastructure 
(though I'll have to update that list). We can and should continue this.



> - JUGs then have their own java.net space, that this is all their  
> members really see. 


This will be the case when we make our groups into projects. In effect, 
it's true now but implemented awkwardly.


> Also  more organized JUGs also have their own
> (outside java.net) web space. Since JUG members are Java developers  
> that care about the technology and learning how to use, etc, they can  
> do this under each JUG, even if they never care for the "JUGs  
> Community" itself. Most developers don't anyway.
> 
> - This may look like "dividing" the community, but it is actually  
> empowering the local communities. 


Not at all. It's just organizing it.


> UGs will bring local developers  close 
> together, and support their activities. Developers will also  
> participate on the larger community by themselves (like joining other  
> forums and projects), but when they have a place they can come to to  
> discuss and defend their local interests, it is easier to get their  
> companies involved, they get more attention, etc. Without UGs, we  loose 
> the capillarity, and all needs to be done "over the web", where  it is 
> harder to relate to each other. And UGs will always be a  division, 
> because each will do pretty much the same thing of every  other, but 
> with a local focus. This is actually a good thing :-)


Agree.


> - the main problem with a "JUG as a project" approach is that usually  
> UGs don't "get it" right away. They will create the project, and not  
> know what to do with it, because projects are focused on code  
> activities, not really on what UGs do (presentations, events,  
> discussions). This is a flaw on the infrastructure used, that most  JUGs 
> will try to compensate by having parallel lives on sites like  Yahoo, or 
> hosting their own services.
> 
> Hope those past experiences with JUGs can help structure the  
> OpenSolaris UGs Community.
> 
> Bruno.

Very helpful. Thanks ...

Jim