Thanks, you have a great week too
And no offence is taken. I think this is a good discussion about how to organise community participation and development processes. Let me try to outline my thoughts on the points you raise.
We have decided to have two different types of XOOPS.org sites: user oriented websites (with a shared userbase) and developer oriented websites. This has been considered carefully, although it doesn't mean it is
the solution.
XOOPS has been a development oriented community for a long time, but the growth of the userbase and support requests made it more and more difficult and complex to manage this properly. On the one hand, developers felt too much pressure from all these support requests, that they didn't enjoy developing their modules anymore. And since passion is a key element in open source development, we felt that we needed to create an environment where the developers could focus on what they are good at: writing code.
At the same time, I created a team that is good at writing user documentation, which is a big request from the community.
The upside of this is that those
inside these teams have the facilities to do what they do best, for the benefit of all. They can focus on the job at hand and have the tools to do that. The fact that they're subcommunities also helps: likeminded people who they know better then a regular community member, who they are collaborating with and use as sparring partners generate a higher productivity then a more anonymous setting.
The obvious downside is that those
outside those subcommunities feel left out -much like you describe yourself- and rightly so. We're trying to find the right balance between the nessecary privacy for the teams to do their work, and the equally nessecary openness that allows for community participation. And that balance is different for each development project.
In seeking this balance I have represented the user view (public unless...), while the developers have taken their view (what works best to get the job done...). Because the developers want (need!) their privacy, the development websites (docs and dev) are partially closed for non-developers. The reason developers have to apply for membership is to keep it as active as we can. And because security vulnerabilities are discussed there (if we find one, we fix it, so don't say that info needs to be public!) that we want to keep hidden from public eyes as much as possible.
Now lets put this next to the wfsections release by Catz. He developed this on his own, not using the shared environment of the Development Forge, which is his porrogative as a developer, of course. He set up his own support site for this module (wfsections.xoops2.com), and chooses to develop this odule by himself. I know Catz didn't have much time recently, hence his departure as the Module Development Team Leader and the subsequent lack of development in the wfsections module. But that is all in the game of open source development. Those community contributions have been added to his latest release.
However, the rules of open source development is that you are allowed to change the code and release it to the public. So you don't
have to wait for Catz to release a new version (that's how xfsections was created). owever, in a perfect world, all these development projects are public, and everyone can contribute. That is the idea for the dev.xoops.org Development Forge, the projects are public and you can add your requests, bugs and patches there. It is up to the lead developer what he/she does with that, much like the wfsections development.
I hope this makes it a little clearer for you
Herko