My vision
1/ to make dev.xoops.org the one stop shop to pick up modules and their updates - I think the module library should reside there.

5 create an Assured Developer program. Will enable a module to be 'xoops accredited' by going through a QA process prior to release that ensures it conforms to development guidelines etc and behaves in a conformant fashion. This program will also help pay for dev.xoops.org

I don't understand some things about it, like where do I have to input the code in and where do I have to put the file in? In what map?

save your file as filename.php and no longer filename.html! The extension is important! Now when you call filename.php it will be perfectly included into your XOOPS theme

instantzero wrote:
Documentation is like development, there are a lot of treasures in the local support sites.
What about a common work ?
A common plan, then a common documentation and to finish, everybody translate it in his/her own language.
Like this we could have a unique documentation, available in many languages.

davidl2 wrote:
To allow people to work together, and to produce the definitive documentation - and to allow people to work on translations together.

MadFish wrote:
I thought a few weeks ago a few people had started jointly writing a vision statement or manifest for XOOPS. I thought it was quite good but problem is I can't find it (all I remember was I think carnuke/rabideau were involved).

Might be useful if someone can dig it out?

carnuke wrote:
This is a long post, but it encapsulates some important stuff. I hope it is helpful

There are some crucial issues here that I think need to be explained.

Open source development is usually driven by developers who expand their projects to make them available to public involvement. The project itself is both a concept and a codebase, that is, it has an objective to be useful, entertaining or informative and the code is built to support that objective. Most open source projects begin by developers promoting their code and concept and build on the project from there. Projects usually start from a small idea, even just a single developer who does the whole thing by him/herself.

Up to a point this all works fine, the developer may get some interested people to help develop and test out the code and develop the project further. The problems set in when that project gathers a certain critical mass of followers and users of the code. Gradually the developers see that there is a need for documentation, Organisation, communication of updates, news, file downloads, etc, etc. In effect all this extra stuff is nothing to do with the codebase or the concept; it's the needs of the greater community. It's meta to the real heart of the stuff and can become a real pain to deal with.

So here is where we go wrong and this is not just XOOPS but endemic to many such larger projects. The developers feel quite rightly, that this is 'their baby' and no-one and nothing is going to part them from their work and Kudos. So they hang onto everything. They continue with coding and developing the project and try their danrdest to throw out some help files, run a forum, make archives available and generally run the whole show.

If they have other developer helpers, they will try to divide the duties, giving a real effort to organise and produce meaningful feedback and content for their beloved community of followers.

Sounds good -eh? does it begin to sound familiar also?

Notice one thing here: The people running the project are all probably developers, who really have one main interest and skill and that is erm ... writing code and developing! Whet they start to find is that the demands of their community of followers is taking more and more of their time which they would rather be spending in cutting good code. But they have to maintain the community, because this is their support structure, this is their Kudos and this is their ready audience to approve and accredit their marvelous project.

Soon the cries of documentation, Organisation, communication and forum participation have angry overtones of disappointment from the community. Great software, but where is our support? we need you, we want you, you have an obligation to us.

What's happening now? The developers are torn, both in their commitment to the project codebase and the community needs. They are distracted by what they should be doing and what they feel obliged to do. The codebase begins to suffer as their time is divided. Feature requests pile up, bug reports flood in, their family/ social life suffers and everything goes pear-shaped.

So what has gone wrong here? if this is a real model of what can happen, what should we do to prevent this happening?

1- The first problem is that the initial developer/s need to understand something. There is a world of difference between running a code based development and running the needs of a support community. They are NOT the same thing. They both need different skills, approaches and support structures. Many developers think they can do it all and that is a mistake.

2- The second problem is that the developer/s hang on to their project and try to quickly learn the skills of communication, management and leadership as well as continue to write and develop the codebase. Big mistake. No one person can do that.

3- Big mistake no 3. You may be an excellent computer programmer, you may be able to write code to dazzle your peers, but that is no indication that you have the skills or qualities to be a manager, or a leader.

4- The time factor. You just can't do it all! Something has got to give ... you know as a developer how many thousands of hours it takes to craft that code base. You simply won't have the time to commit to further duties and do a good job.

5- Attitude. You know that programming develops a certain type of 'mindset' you see things in terms of 'on' or 'off' Black and white. Yep, that's part of the attitude of mind that coding requires. The problem is that people are not like that. Many of them are ordinary users, who know tiddly-squat about your code base, they just want the goodies. It's not right that you should talk to them in technical terms that they don't understand and it will probably hard for you to translate their 'layman' language into meaningful code ideas.

6- Leadership and management are not the same thing! As a developer and programming specialist, what do you know about that? Are you aware that there is a whole set of different skills required to lead a community and that to manage the structure of support for the community is likewise totally different from leadership? If you have business skills and training, you will know this.

7- Firefighting. That's the worst problem of all. This is the critical stage where a project starts to fall apart and break into factions. The developers are now self appointed leaders, managers, communicators and administrators. Oh, and coders as well! They desperately try to keep 'all the plates in the air' and hope to god they don't drop any. But they eventually do. Firefighting is a perilous job, it's ugly and destructive and makes everyone look ridiculous.

The solution:

Phew!, here's the good bit, but with a serious and difficult caveat at the end. When an open source project starts to develop publically, there are some critical changes that must take place. It's called 'Forward planning', or if you like a road map

1- If you are a key Developer or owner of the project, here are the key things you must do when your project reaches a certain critical mass with community followers:

- know your limitations,
- know where your skills lie,
- prepare to delegate responsibilities,
- let go of your egos,
- seek out managers to manage,
- understand the meaning of leadership, and let one arise.
- be prepared to let another take center stage in the community sector,
- don't interfere with another man or woman's skills,
- Realise that you are now another contributor, not the king.
- In short, become a team player (ouch!)

Now the painful caveat ..

What do we do if a project has already got to the firefighting stage? how do we recover what has been lost, corrupted, destroyed and the people that are hurt?

1- You have to collectively say the word STOP! and draw a big red line here.
2- That means everyone, including those people who are firefighting.
3- What's already burning probably needs to go anyway.
4- Someone needs to take a position of leadership.
5- The rest of the community needs to stop all the 'static' and listen...
6- A 'true leader' will know how to pour soothing oil on the wounds, but also speak with strength, dignity and authority.
7- S/he will immediately recognise and collect a small team of people who can manage.
8- S/he will delegate jobs to them, based on their wider experience and skills.
9- S/he will understand the needs of human reconsiliation as well as the codebase needs.
10- A true leader is able to let go of demonstrating his authority through ego and power.
11- A leader does not try to manage the people, s/he manages the managers.

And the difficult bit? ... it's turning off the 'static' it's drawing a line, it's the doing of it.

The situation in XOOPS at the moment follows closely the model outlined above. We have developers hanging on to leadership and firefighting. We have people who are skilled in computer programming who have been seen by the community as key players and thus deemed suitable as managers and leaders. They are not, they have not the right nor the skills to be there. They are compromising not only the requirements of the community, but also the codebase development. They need to let go of their egos and we ned to to release them to do the job that they are skilled and respected for.

What XOOPS needs now is to draw that line and let go of the small developer based mindset. This is now a large community that needs real leadership and a proper management structure. We need developers who have the space and time to do just that and nothing more required of them.

Again I ask the question, can we recognise it, can we do it, can we evolve into what we should be?

tom wrote:
The XOOPS Communications Team Proposal

Tasks:

- Community coordination
Team will fall under it's own - [XoopsTeam] progress - community coordination - June 10th

Currently open to applicants and suggestions.

- Translations
-- Translate to other languages for use in international support sites

instantzero wrote:
Excuse me for asking another question (suggestion in fact) but their are some treasures in the local supports.
And those people do not always speak english.
I think it will be good if they could join the new Xoops.
Can I suggest to wait, or to verify, that the good news is spread everywhere (in the local supports) so that everybody can join ?

Please be patient just a little longer. It will be well worth the wait. I promise! "Good things come to those who wait [patiently].

Do not use the WordPress mu. If you really need a multi-blog multi-user blog system, lifestyle is much better than wordpress mu although I have always been looking forward to a really multi-blog from the wordpress dev group.