Quote:
eric235u wrote:
my goal was to wait for one of the sourceforge admins to post but since others have requested a plan here is my first attempt. i look forward to community input. - eric c
As James wrote in another post, the sf.net project admins are core developers. They're the development project admins, not the community support admins. IMHO split these two apart, and the whole leadership issue becomes easier to solve. The core development already has leadership, it's the support community that lacks it. IMHO, this isn't a bad thing per se.
I'll give you my input, which may seem sceptpical, but this is based on 3,5 years of XOOPS management experience, longer then anyone here.
Quote:
1. All XOOPS decisions are made in public with community review and input. Reason: to foster community transparency and trust.
All XOOPS decisions are made in public --> All XOOPS support community decisions are made public.
If you stop and think about what decisions we're talking about here, then these are mostly practical issues on who does what with news, moderators, FAQ and such. This doesn't really require an overseeing and coordinating leader IMHO. See points made in previous posts in this thread.
Quote:
2. The XOOPS sourcforge wiki will become the focal point for core XOOPS documentation. Reason: to have a central and up to date source of information.
First it was docs.xoops.org, then xoopsdocs.net, now the sf.net wiki. A lot of talk about the location and tools used, but what about the actual writing of the docs? Who cares really
where they're made? It's about writing them...
Quote:
3. Use either CVS or SVN not both. Remove developers who have not been active in the last 3 years. Remove dead modules. Reason: this is our most important resource and therefore should be well managed.
Core development team decision. Simple. Why would an overseeing coordinating project leader need to make these decisions on how the developers do their work? If svn and cvs are necessary (and its the developers who make that call anyway), why don't we let them keep it? Parotting experts decisions and making them 'official' is one of my own mistakes, and I propose everyone learns from them
Quote:
4. Use the sourceforge developer mail list as the focal point for all developer communication. Reason: Everything should be documented. This will allow us to understand our history and to make better decisions about our future. It also builds community trust if regular users can see what developers are discussing, whether or not they have the technical ability to take part.
Again, a developers call, not a community leader's call. This is a change? See the trackers and forums on sf.net. It already works like this.
Quote:
5. Do not be rude. All technical discussions allowed, personal attacks are not. This is mostly already enforced. The reason for this is self evident.
Pfff. If this should come from a leader, it sounds patronising. Don't get me wrong, I fully agree with the point, but that's like saying 'If I get voted in, I'll say that you have to abide by the law'. It's about how you intend to keep people to their promises and how to keep them from misbehaving. That's what leadership means IMHO.
Quote:
6. XOOPS social structure should be a Consensus-based Democracy and when we are deadlocked we vote. All XOOPS members have one vote. XOOPS sourceforge admins have veto. Reason: people seem to feel more confortable and participate more in concensus based structures.
Nonsense. People don't vote because they're more comfortable, they vote to make themselves better. Since when did anyone vote for the Greater Good? And then vote on what? Vote on who will do all the work? Vote on what needs to be done? Then what? Voting isn't the answer.
I'm with the meritocraticists here. See my previous posts.
Quote:
7. The immediate creation of voluntary XOOPS teams to focus on concerns raised in this thread. Such as Core, Addons, Community, Publicity, International, etc. To be created, changed and removed as the community sees fit. Reason: we currently have several seriously negleted areas in the XOOPS community that would greatly benifit from official XOOPS teams.
Been there, done that. This was called the Core Team, then the Management Team. Honestly, it's all been done before. And I don't see what will make it a success this time.
Quote:
8. Monthy ‘State of XOOPS’ newsletter written by the Lead Project Manager and other volenteers to discuss progress of initiatives. Reason: to have a clear roadmap of our progress easily accessible by all community members.
The last 6 newsletters would have said 'On Hold, please check back later'.
This however is a good idea (and again, definately not a new one). Find out why the current World of XOOPS newsletter isn't reanimated, and you'll know what to fix. But it definately wasn't a lack of communication by the management.
Quote:
9. The Lead Project Manager is a two year position. At the end of every two year cycle there is a popular vote for a new Lead Manager.
IDOLS ALERT!
Seriously, the temporary bit I like, the voting bit I hate. Better way is to have the period set by the goals that need to be achieved. Like: XOOPS 2.3 released, 20 new documents for users, 5 new core developers, 75.000 registered members, 2500 daily downloads, etc. If they're reached, the community will discuss new goals. And then the method of reaching them is decided.
Again, IMHO ther eis no need for an overall encompassing coordinating leader at the moment. What we do need is active core evelopment, which is already happening (see the trackers for this). What we also need is new life in the XOOPS Foundation so real work can be made of the corporate side of XOOPS: marketing and promoting the XOOPS product to the masses. And the community needs to stop looking for other people to do the work for them
Herko