It seems with all the talk of new teams, councils and foundations are superseding the real issues right now. If XOOPS is to succeed we actually now need to take a few hundred steps back and begin again with what is the real core issue at Xoops. The Core code! Without the code all the new teams are pointless, so lets get to what is at the heart of the matter.

Cycle of life
ref:http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle
working study:http://dev.joomla.org/content/view/39/63/

Before we can start work on XOOPS again correctly and in a positive manner, we need to establish a working frame work for development and it should be followed to the letter at each cycle of development. So far the current thinking is we just add stuff as we go, this is just so wrong on so many levels and creates for an unworkable environment.

Gone are the days when one developer just adds to the code because they believe it is the best for Xoops. We now need to listen to the community and learn their needs and wants. If we put in place a 'cycle of life' approach' we can better approach the real development of Xoops.

Communication is a vital factor for ever stage of development.

Roadmaps

Why are roadmaps important, because they outline what is about to happen and when they will happen. The end-user will have a visual representation of the tasks at hand; this promotes confidence and the less chance of hearsay creeping into the development cycle.

Who creates the roadmap? Actually it is the community that creates the roadmap. Without the community input at the beginning of the cycle the developers would have nothing to work with.

This website gives a very simplistic view of the approach we should actually take towards our own development cycle.

Ref:http://aspalliance.com/1017_Software_Development_Life_Cycle

We need to start the first stage of this process now, it is important for the further development of Xoops. No longer can we afford to ignore these stages of development and leave the development in the hands of one person. You decide what you want, we give you a realistic goal of achievements to finish the work and then start on the next cycle of development.

Release Models.

The current release method for XOOPS requires a new approach. The current method leaves a lot to be desired. We cannot just release a new version because we feel like it.
Security or bug related releases are the only permitted out with the development cycle.

Development Discussion

I strongly believe that if XOOPS is to get back on the right track, we do need to be a bit more open in out development approach. We need to make the community feel that they are part of this process and they have their say in what they would like in their Xoops.

We need to bring this discussion back to the XOOPS forums for all to see and discuss (not just the developers who will visit sourceforge). The current premise is, if your not a coder don’t get involved in the coding process, this is totally wrong. You don’t have to be a coder to have good and interesting idea’s that would make for inclusion within the XOOPS roadmap.

Lets build XOOPS together…………

You made some good points there.

At the core developers meeting yesterday, personnel were assigned to the tasks of getting 2.0.17 and 2.2.5 released. (The meeting notes will be published shortly.) These are only bug-fix releases, I think, so there shouldn't be any controversy here.

As the one assigned to handle 2.2.5, I will be asking for feedback from the community on any bugs that I may overlook.

The longer term task of merging the 2.0/2.2/2.3 branches is still being discussed. I think everyone would agree that these branches do need to be merged; the issue is "how". When a plan is decided upon by the team, it will be posted for public feedback.

The core dev team will also be posting periodic status reports.

So I think we're on the same page here.

The Community Coordination Team is being formed and will be coming on line shortly.

When we submit a bug report or feature request:

How do you want it submitted (SF.net, dev.xoops.org, here, etc.)?
What information do you need included?
What information would you like included?
Do you want it in a specific format?
What do you need from us to make your job easier?

After we submit a report or request how can we get regular updates regarding the issue?

KC0MAZ
Community Coordination team leader (elect)

Hey cats, very glad to see old guys like you and predator being back, not only appearing on xoops.org but also joining development discussions ;)

As Dave_L said, the core development team had its first team meeting and the team starts from now. You are very welcome to core dev's forum at SF for detailed discussion.

Yes I read this the topics over at SF, my question being this! Why do you feel it necassary to hold these meetings over at the SF site and not open over here? Personally I feel you are splitting the communtity into a 'Them' and 'Us' senario. We shouldn't forget that people we are doing this for, their input is just as important as a developers in many respects.

Quote:

Many good questions that would simply would have been answered if we had a good FAQ regarding this and many other important matters.

A personal fav of mines what to be able submit bug reports from the admin area.

The fact is that submitting a bug is only part of process, it doesn't matter how many bugs that get reported if they are not acted on. Bugs should have a critera of importance and severe bugs/security issues should be fixed and made available within 24-48 hours and not as in some cases ignored or debated about for weeks on end.

Quote:

The Report Core Bug item in the main menu (titled 'Community') would be my first place to submit. And, when you follow that link, there are some pretty good instructions there that answer your other questions.

Submitting the bug there provides tracking, too.

Quote:
I'm sure if I searched hard enough I can find different versions of what you need. There lays the problem, what do you need, what do want, and can you do without.
Quote:
That is our problem. When we get our hands on an issue, and we can not find the answer in the documentation, user forums, or any other resources, then we collect the information you need or want and submit to developers. Issues reguarding unclear documentation, is submitted the documentation team including missing FAQ's
Quote:
You are correct, and I am not going to debate that issue with you. In the near future I would like to see a 'fast track' process, where severe bugs and security issues are sent directy to developers,by-passing normal channels and an response given within 30 to 120 minutes.

But we all have dreams

Quote:

I will clear up my previous statement. When I mentioned the admin area, I was of course talking about the admin area of your own XOOPS install.

Giving the admin the ability to report bugs from the backend would collect as much information via the script regarding the users own environment/install/OS etc and send that information directly to XOOPS etc.

This would then eliminate as much of user input as possible. Much of this was planned with me and mekdrop over at Zarilia. It isn’t that hard to implement actually.

Discussion and Roadmap -- agreed!!! I believe that Catzwolf brings up many good points. Code is certainly the main issue. The rest won't matter. But, I do believe that our somewhat fractured community needs to reorganize.

I come from a grassroots community organizing background. I do believe at this point that the Core Dev Team and the Module Dev Team are working to achieve the input aspects that you are talking about. The emphasis seems to be in the right direction on those two team with which I have volunteered to work.

While we are focusing on moving XOOPS forward, getting a bug-/security-fix out quickly for both branches, we are also looking at ways to organize the teams. Getting an organization in place is paramount to ensuring that we have a solid code base for XOOPS that meets the needs of the community.

When I say organization, I generally mean one with a more flat hierarchy with tri-chair coordinator/managers who are held accountable for aligning their teams work with the roadmap that is developed through a community feedback process. It's positive that there are driven people here that are passionate about the XOOPS direction. I certainly have my own ideas about it, too. But, we have to come up with a flexible, grassroots organizational structure that has openness, transparency, but at the same time makes stuff happen, and the only way to do that is to empower people -- just not too much. People will be asked to take on leadership roles, but these roles need to be shared and communally done (thus the tri-chair idea). This way it's not any one person running anything, and meetings and forward movement aren't held up by any single-person bottleneck.

Key points for me to have a successful community are:
* Empowerment (empower everyone to contribute how they best are able)
* Process (documented processes that makes it easier for everyone to understand what is going on in every part of our community)
* Openness, Transparency (all long-term directed movement by the community, foundation, etc., need to be done through an RFC-like process)
* Flat Hierarchy (the idea here is to make it the community's organization and to take ego's out of it and make no single person more important than others because of the position to which they are elected/appointed; great ideas and architectures will rise to the top because they are the best suggested)
* Forward Movement (this is the most important one. We must have progress, and the community must get it regularly. I'd prefer something like the Ubuntu community's with scheduled releases both for bug/security fixes as well as minor/major releases).

The Core Dev Team met yesterday, and the focus was on all of these things. The entire community is struggling to figure out how to work together, how to move forward, how to involve people, and the direction to go. There is much FUD (fear, uncertainty, doubt) going on because of all the changes. Change makes people uncomfortable. Personally, I'm excited that this movement is happening because nothing has happened for so long.

For any relationship, communication is key. We will not all agree on everything. However, I think each person needs to look at what is going on and ask themself, does 75% of you agree that this would be the way to move forward. I.e., how strongly does the particular issue matter to you in the overall grand scheme of things and issues of XOOPS? Let's keep the communication going, and let's keep it civil, issue-related (no personal attacks/insults/etc), and figure out how to move the mothership.

Working together, we'll create change, and make a difference. Within a year or two, my hope, desire, and long-term vision for XOOPS is to make it the #1 CMS. We can do this, but only if we throw aside any ego-personality crap and figure out how to work TOGETHER on all this.

Onward through the fog....