Please see my inline comments below.
On Tue, May 7, 2013 at 9:18 AM, Brian Cluff
<brian@snaptek.com> wrote:
On 05/07/2013 06:59 AM, Lisa Kachold wrote:
1) No delegation from the top.
2) The top = a "One Man Show"; rather than an organized decision group
made up of assigned officers with a clear responsibility, delegation
powers, access and term. This limitation in a process analysis equates
to "spoke wheel management"; wherein the bandwidth bottleneck of the
single management entity limits the ability for the group at every
level. So, as far as I am concerned, until this factor changes, the PLUG
will always have huge limitations and no bandwidth to do more; people
wanting more will be alienated or frustrated, etc.
A "steering committee" is clearly not a group of officers, with a mission, term, and empowered to meet various roles in the community, therefore, the loose, possibly anarchic PLUG control and growth never evolve. Did the PLUG ever obtain non-profit status riding under another 501-3C? Why not? Where was that delegated, how are programs developed; funding requested from LPI Institute, or interns and mentors sent along to Google Summer of Code. Clearly all this is doable, but will never happen from a "Steering Committee". Can you tell me who are the members of the Steering Committee, and what they do or just who decides who is on that Committee (again Hans, right)?
I am not just complaining, I am comparing from an educated experienced viewpoint, for the purposes of PLUG Change and GROWTH!
For instance, compare the structure of the Portland Linux User Group:
http://www.pdxlinux.org/ hosted at Spiretech.com where I worked for 8 years as Senior Linux Systems Administrator in late 1990s. Their Advanced Topics meet at FreeGeek where I taught in 2004. FreeGeek itself exists as a great example of how a community non-profit can be run to grow and remain viable.
See very old Documentation on How To Maintain a LUG:
Excerpt:
- Make the barriers to LUG membership as low as possible.
- Make the LUG's Web site a priority: Keep all information current, make it easy to find details about meetings (who, what, and where), and make contact information and feedback mechanisms prominent.
- Install distributions for anyone who wants it.
- Post flyers, messages, or handbills wherever computer users are in your area.
- Secure dedicated leadership.
- Follow Linus Torvalds's benevolent dictator model of leadership.
- Take the big decisions to the members for a vote.
- Start a mailing list devoted to technical support and ask the "gurus" to participate on it.
- Schedule a mixture of advanced and basic, formal and informal, presentations.
- Support the software development efforts of your members.
- Find way to raise money without dues: for instance, selling GNU/Linux merchandise to your members and to others.
- Consider securing formal legal standing for the group, such as incorporation or tax-exempt status.
- Find out if your meeting place is restricting growth of the LUG.
- Meet in conjunction with swap meets, computer shows, or other community events where computer users -- i.e., potential GNU/Linux users -- are likely to gather.
- Elect formal leadership for the LUG as soon as practical: Some helpful officers might include President, Treasurer, Secretary, Meeting Host (general announcements, speaker introductions, opening and closing remarks, etc.), Publicity Coordinator (handles Usenet and e-mail postings, local publicity), and Program Coordinator (organises and schedules speakers at LUG meetings).
- Provide ways for members and others to give feedback about the direction, goals, and strategies of the LUG.
- Support GNU/Linux and free software / open source development efforts by donating Web space, a mailing list, or an ftp site.
- Establish an ftp/Web site for relevant software.
- Archive everything the LUG does for the Web site.
- Solicit "door prizes" from GNU/Linux vendors, VARs, etc. to give away at meetings.
- Give credit where due.
- Submit your LUG's information to all the LUG lists.
- Publicise your meetings on appropriate Usenet groups and in local computer publications and newspapers.
- Compose promotional materials, like PostScript files, for instance, members can use to help publicise the LUG at workplaces, bookstores, computer stores, etc.
- Make sure you know what LUG members want the LUG to do.
- Release press releases to local media outlets about any unusual LUG events like an Installation Fest, Net Day, etc.
- Use LUG resources and members to help local non-profit organisations and schools with their Information Technology needs.
- Advocate the use of our OS enthusiastically but responsibly.
- Play to LUG members' strengths.
- Maintain good relations with vendors, VARs, developers, etc.
- Identify and contact consultants in your area.
- Network with the leaders of other LUGs in your area, state, region, or country to share experiences, tricks, and resources.
- Keep LUG members advised on the state of software -- new kernels, bugs, fixes, patches, security advisories -- and the state of the GNU/Linux world at large -- new ports, trademark and licensing issues, where Torvalds is living and working, etc.
- Notify the Linux Documentation Project -- and other pertinent sources of GNU/Linux information -- about the documentation the LUG produces: technical presentations, tutorials, local HOWTOs, etc.
HOW MANY ARE WE ACTUALLY SUCCESSFUL WITH? WHY?
3) Poor control of and development of the PLUG Website; content
submissions are too limited for each group, so value is lost every week.
You're the only one saying this. Most people are saying quite the opposite. Just about everything that is submitted makes it to the website... the problem is that there aren't a lot of things being submitted since we usually have trouble getting a presenter until just before the meeting starts.
What changed on the website is that we changed from a place where we allowed just about anyone to do whatever they wanted to the website whenever that felt like it, which was causing more problems than it was solving, so we switched to system were we have a small number of people that have direct access to the website so that it can remain a quality resource.
I agree that we have a limited number of people involved with any type of the vision and competency that Hans or you have. Your contributions have been great.
I believe that the limitations in the PLUG are inherently due to the limited structure, the professionals in Arizona, who tend to be conservative, doing only what serves them. The PLUG at it's current organization is limited and that limitation of structure and vision limits our professional and greater open source community involvement.
My intention was not to BLAME anyone, but to show the wider systemic view related to differences and best use of social networking, including automated tools, which my critique has taken the focus from.
Can you imagine what the kernel would be like if they gave commit access to everyone who felt like they wanted to contribute to it?
I can script or crontab a backup for the website that would allow more than one or two people to maintain (read control) it. I can configure a CMS that will allow submissions from community to be REVIEWED before release. If this was not included in the new web build (also controlled by 2 people - You and Hans) I would have to say why not?
The kernel development commit access allows for trivial roll forward and back and the project is run with more than 2 people so the BANDWIDTH excuse is rarely heard.
Modules exist to automaticly cross post to all of FaceBank, LinkedIn, Twitter, and GoogleGroups or Google+ that could be best integrated with the PLUG site.
Brian Cluff
As always, it's a great pleasure to