Commission to Reform WPLUG: Difference between revisions
| Line 129: | Line 129: | ||
One thing we need to keep in mind, as we plan alternate events (such as social events and such) that might take place at a public venue - we absolutely must engage with the venue to make sure that we are welcome, and that they are willing to accommodate us, and we need to do this before any announcement is made of the event or the venue. This is a mistake that we made with the failed bowling event, which we don't want to repeat - we showed up unannounced, assuming the venue would surely be happy to accommodate us - and, as it turned out, they weren't. |
One thing we need to keep in mind, as we plan alternate events (such as social events and such) that might take place at a public venue - we absolutely must engage with the venue to make sure that we are welcome, and that they are willing to accommodate us, and we need to do this before any announcement is made of the event or the venue. This is a mistake that we made with the failed bowling event, which we don't want to repeat - we showed up unannounced, assuming the venue would surely be happy to accommodate us - and, as it turned out, they weren't. |
||
==== Remember that there is an Event Committee ==== |
|||
Section 7.2 of the Bylaws gives the Event Committee the authority to plan events in the name of the organization. The full board doesn't need to be involved with, and approve, each event. This is, of course, more important in an environment where the Event Committee is not a proper subset of the board (which it now is for the first time, I think, in the last three years), and particularly if we can get more people involved. The reason I point this out is that of late, the event planning cycle has mostly been demarcated by board meetings, and it doesn't need to be that way. The event committee can hold it's own meetings, on it's own schedule, and we should leverage this (especially, as I said, if we can get additional people involved in event planning). |
|||
== Accepted Reform Package 3 Proposals == |
== Accepted Reform Package 3 Proposals == |
||
Revision as of 06:09, 27 November 2013
The Commission to Reform WPLUG (CRW) is an informal group created to draft proposals that fix long-standing problems in WPLUG. It was created on December 9, 2012.
Purpose
WPLUG is struggling to compete against other technology groups. CRW's purpose is to expedite the reform process so that WPLUG can become competitive again as soon as possible:
- Update the bylaws
- Chart a new direction for WPLUG
- Explore ways to make WPLUG less formal/political
- Bring WPLUG's resources up to par with current technological standards
Operation
CRW has no membership requirements. If you decide to join, add your name to the membership list on this page.
Each month, CRW gathers its best ideas into a "reform package" that is formally proposed during the following month's WPLUG general user meeting. Ideas can be proposed or voted on at any time, but it is recommended to propose ideas outside of meetings and vote on them during the meetings so that people have time to think before they vote.
If an idea is approved by a majority of CRW members, it will be added to the current reform package.
Since CRW is not an official WPLUG organization, it doesn't receive official funding and is not governed by the WPLUG bylaws. Members are encouraged to apply the same "free and flexible" mindset to their deliberations: check your preconceptions at the door, be open-minded, and support the best ideas to reform WPLUG. Everyone who wants to present ideas will have an equal opportunity to do so.
Members
- Justin Smith
- Terry Golightly
- Pat Barron
- Vance Kochenderfer
- Joseph Prostko
Meeting Logs
Upcoming Meetings
None at this time.
Reform Package History
Reform Package 1: Bylaw changes, presented at January 2013 GUM.
Reform Package 2: WPLUG's general direction, to be presented at February 2013 GUM.
Reform Package 3: Focus TBD. To be presented TBD.
Reform Package 3 Ideas
Vance Kochenderfer
Event frequency
In my view, WPLUG needs to have at least one event per month. Even better is if we can have three or four months with two events (say, September with Software Freedom Day and another event).
Types of events
There need not be a General User Meeting (GUM) each month. I think some variety encourages different types of people to attend. Installfests and social events are acceptable. I do think the GUM is the long-standing "standard" event, and we should probably shoot for at least six of these in a given year.
Meeting venues
I really am a fan of the WSCC. I recognize that they charge for room use, and that there are fewer public transportation options. The big difference to me is that we are welcomed there, rather than simply tolerated as was the case at CMU, and it serves as a stable home base. Carnegie Library is OK for occasional events, but AFAIK will not permit us to hold all our meetings there.
A company or university meeting room is a fine location, but relies on having a person connected with that company or university to secure it for us. I'm glad Pat has been able to get us into IBM, but attendance doesn't seem to have been very high there - despite survey comments, I don't think the downtown location is preferred over Regent Square by our audience.
If we are facing cash flow problems with the small amount WSCC charges for rooms, I'm happy to pony up for that, and we can solicit contributions in addition to membership dues.
- Vance (talk) 02:30, 26 November 2013 (EST)
Justin Smith
The way I see it, we've got three main problems.
Too many GUMs
Having formal meetings on a monthly basis is fine if you've got people clamoring to present, but we don't. Therefore, I think we'd do well to have them once every 2-4 months. Since we're not sure how people would react to the social events I presume we'd be filling our off-months with, I recommend taking a conservative approach. Let's start with having GUMs every other month and see how that goes. If it's still too often, we can increase the interval to once every three months.
Event planning takes too long
We should be mindful of how long our event planning takes. Every time we want to hold an event, we have to start planning from scratch because we don't carry over themes from one event to the next. That's inefficient, and it isn't easy on our already-limited resources. Instead, let's split up the year into blocks of two months (or however often we agree to hold GUMs) and agree that all events in a given block will follow a given theme. We can either hold social events that build up to a GUM or hold a GUM and then have social events that build on the idea that was presented.
Not enough cohesion between events
For instance, let's say our theme for the January-February block is running your own Linux server. (This is an example, not a suggestion.) Someone gives a presentation about the uses for a Linux VPS and leaves people with suggestions for providers they can use to get started. (This is also an opportunity for us to earn commissions - just saying!) At the end of January, we hold an IRC chat session where people can come in and talk about how they're doing so far. In February, we hold a "Project Night" at some physical location where people come in and work on VPS stuff together - kind of like we did at the last GUM, except it's more targeted.
Remember how we were talking about holding classes? I still don't think we have the resources to do that, but linking events together might give us some of the same appeal. We'd be taking the time to really drive home particular topics. Maybe that would make people more likely to attend!
Pat Barron
GUMs, Events, and Business Meetings
I believe there is some confusion among potential attendees about what they are going to encounter when they attend one of our events - particularly among those potential attendees who aren't fans of a lot of "rules", and don't want to sit through a business meeting. I think there isn't sufficient awareness that we don't hold a business meeting at every GUM (the Bylaws now require us to have only one business meeting per year, though I in no way recommend that - I think we should have a business meeting at least quarterly). Even on occasions when we don't hold a business meeting, I think it should be made completely clear in the schedule when the business meeting starts, and when it ends (and we need to stick to it) - and, we should have a specific committed time when the technical or event programming starts, and emphasize in the meeting announcement that non-members (and members who simply don't want to attend a business meeting) need not arrive until the time designated for the programming to start. Even though this is normally listed in the event schedule, I believe we should actively emphasize it in our meeting announcements.
Not enough programming content
I don't think it's necessarily the case that we hold too many GUMs, and it would certainly be my preference to hold one event per month on a reliably predictable schedule. However, I don't think we should even attempt to hold an event if we don't have some kind of solid programming. If we're coming up on a "normal" GUM date and don't have a solid program already booked, we're probably better off just not having the GUM at all.
Too much programming when we do have programming
We shouldn't try to stuff too much programming into a given event. Unless we're doing a lightning talk event (where we really do need to enforce a hard time limit - the entire concept of lightning talks is almost a "game", where you see if you can get enough content into the very limited timeframe available, that's actually part of the fun of it...), I don't think we should ever program more than one speaker or presentation per GUM. This is especially important when we're meeting at a facility like WSCC, where "time is money" and we really do have a hard stop time. Plus, from a speaker perspective, it is not particularly desirable to a potential speaker to have to sit through another speaker's presentation before doing his or her own presentation.
If we find ourselves in the unusual situation where we have multiple presentations that could potentially go on during a given GUM, we should do our best to push the "extra" presentations out to future GUMs.
Consistency in event announcements
There should be an event announcement each month, without fail. Even if the announcement is, "We're not holding an event this month". At least this reassures people that we're still here, and thinking about the event schedule - and reminds them that we do hold events, even if we're not having one during that specific month.
Event planning cycles are much too short
This may just be another way of stating Justin's point about "Event planning takes too long" - it's not that it takes too long, it's that we don't acknowledge how long it really takes. We seem to be in a pattern of not really starting to plan most GUMs until the board meeting immediately preceding that GUM. If the board is sitting in a meeting hashing out, "So, are we going to have a GUM next month, and if so, what should it be?", then we're doing it wrong... My view has long been, at the time we hold a GUM, we should already know what's on the program for the *next* GUM (speaker or program committed, venue booked, program already announced to the membership, etc.) - and, preferably, the one after that too. I know, this is much easier said than done - as has already been noted, we aren't exactly overflowing with programming available to offer. But establishing a longer event planning cycle should be a goal.
Venues - positive and negative
I have some comments about meeting venues that, for various reasons, I think are more appropriate to share outside of this forum. Check your e-mail.
Ultimately, though, the primary advantage I see regarding meeting at WSCC is that providing meeting space is what they do. That's their mission. One of the biggest problems with "borrowed" space is that such space is controlled by organizations who have no investment in WPLUG, and whose primary missions don't align with WPLUG's mission. For all kinds of reasons - for example, we lose our "internal advocate" within that organization, or they just have something come up that's more aligned with their mission - we're always at risk of losing such space on very short notice, or even on no notice at all. We're simply not important to them. Oh, of course, we're not *anti-important* to them, they wish us no ill will or anything. It's just that, they larger organizations who control these spaces don't care about WPLUG, per se - we're not on their radar, at all. At best, such organizations let us use such space on the basis of, "if it's not inconvenient for us". At worst, we may become inconvenient, or even somewhat annoying, to other organizations who permit us to use their space.
Make sure the venue is on board
One thing we need to keep in mind, as we plan alternate events (such as social events and such) that might take place at a public venue - we absolutely must engage with the venue to make sure that we are welcome, and that they are willing to accommodate us, and we need to do this before any announcement is made of the event or the venue. This is a mistake that we made with the failed bowling event, which we don't want to repeat - we showed up unannounced, assuming the venue would surely be happy to accommodate us - and, as it turned out, they weren't.
Remember that there is an Event Committee
Section 7.2 of the Bylaws gives the Event Committee the authority to plan events in the name of the organization. The full board doesn't need to be involved with, and approve, each event. This is, of course, more important in an environment where the Event Committee is not a proper subset of the board (which it now is for the first time, I think, in the last three years), and particularly if we can get more people involved. The reason I point this out is that of late, the event planning cycle has mostly been demarcated by board meetings, and it doesn't need to be that way. The event committee can hold it's own meetings, on it's own schedule, and we should leverage this (especially, as I said, if we can get additional people involved in event planning).
Accepted Reform Package 3 Proposals
None at this time