I found it: Tree Magic Charter (this is their new project)

Also worth a read: Ubuntu's Governance structure. Even if we came up with a different system, having something written down in this manner would be useful.

Quote:

you mean similar to this also (a point i made in another thread) > (take note of the phrase zero-tolerance)

The chapter Setting the Tone from the book Producing Open Source Software gives us a clear proven outline of how we can effectively demonstrate how community support should be done.

and to quote:

[quote]
Nip Rudeness in the Bud
From the very start of your project's public existence, you should maintain a zero-tolerance policy toward rude or insulting behavior in its forums. Zero-tolerance does not mean technical enforcement per se. You don't have to remove people from the mailing list when they flame another subscriber, or take away their commit access because they made derogatory comments. (In theory, you might eventually have to resort to such actions, but only after all other avenues have failed—which, by definition, isn't the case at the start of the project.) Zero-tolerance simply means never letting bad behavior slide by unnoticed. For example, when someone posts a technical comment mixed together with an ad hominem attack on some other developer in the project, it is imperative that your response address the ad hominem attack first, as a separate issue unto itself, and only afterward move on to the technical content.

It is unfortunately very easy, and all too typical, for constructive discussions to lapse into destructive flame wars. People will say things in email that they would never say face-to-face. The topics of discussion only amplify this effect: in technical issues, people often feel there is a single right answer to most questions, and that disagreement with that answer can only be explained by ignorance or stupidity. It's a short distance from calling someone's technical proposal stupid to calling the person themselves stupid. In fact, it's often hard to tell where technical debate leaves off and character attack begins, which is one reason why drastic responses or punishments are not a good idea. Instead, when you think you see it happening, make a post that stresses the importance of keeping the discussion friendly, without accusing anyone of being deliberately poisonous. Such "Nice Police" posts do have an unfortunate tendency to sound like a kindergarten teacher lecturing a class on good behavior:

First, let's please cut down on the (potentially) ad hominem comments; for example, calling J's design for the security layer "naive and ignorant of the basic principles of computer security." That may be true or it may not, but in either case it's no way to have the discussion. J made his proposal in good faith. If it has deficiencies, point them out, and we'll fix them or get a new design. I'm sure M meant no personal insult to J, but the phrasing was unfortunate, and we try to keep things constructive around here.

Now, on to the proposal. I think M was right in saying that...

As stilted as such responses sound, they have a noticeable effect. If you consistently call out bad behavior, but don't demand an apology or acknowledgment from the offending party, then you leave people free to cool down and show their better side by behaving more decorously next time—and they will. One of the secrets of doing this successfully is to never make the meta-discussion the main topic. It should always be an aside, a brief preface to the main portion of your response. Point out in passing that "we don't do things that way around here," but then move on to the real content, so that you're giving people something on-topic to respond to. If someone protests that they didn't deserve your rebuke, simply refuse to be drawn into an argument about it. Either don't respond (if you think they're just letting off steam and don't require a response), or say you're sorry if you overreacted and that it's hard to detect nuance in email, then get back to the main topic. Never, ever insist on an acknowledgment, whether public or private, from someone that they behaved inappropriately. If they choose of their own volition to post an apology, that's great, but demanding that they do so will only cause resentment.

The overall goal is to make good etiquette be seen as one of the "in-group" behaviors. This helps the project, because developers can be driven away (even from projects they like and want to support) by flame wars. You may not even know that they were driven away; someone might lurk on the mailing list, see that it takes a thick skin to participate in the project, and decide against getting involved at all. Keeping forums friendly is a long-term survival strategy, and it's easier to do when the project is still small. Once it's part of the culture, you won't have to be the only person promoting it. It will be maintained by everyone.[/quote

Yes I whole heartily agree with this statement and quite rightly too, but you cannot have one rule for the community and one rule for staff. There should be guidelines for moderators and staff when interacting with the community and they should be made aware that their behavior will be moderated and action will be taken against them if they break the guidelines set. If you are a member of staff, your behavior should be exemplary and an example to the community in everyway possible.

When you represent a project or business at a moderation level, you represent the project current status as a whole and not your own personal feelings. So please take into account the next time a moderator or a member of the project team decides to act on a personal level that these guidelines govern their actions in the same retrospect of those in the community. These work for both and not just the one.

yep, i will ask everyone, team members included (and core dev as well), to sign off our manifest,as soon as it's correctly defined and validated.
xoops project is not held by team members, it's a community driven project.
i ask each team member (core dev included) to give its own opinion to the thread. thanks in advance
marco

One vote for Carnuke's treatise. Excellent. Totally appropriate. I tried to intimate towards this in my last few posts, but he says it so much better.

The talk of manners here is kindergarten stuff. Totally correct but my six year old has it sussed already.

The title of this thread is "Moving Forward Past Negative Attitudes". To me, moving forward past negative attitudes means not repeatedly stating the obvious about being polite and civil to one another, no one's in disagreement about that, are they? Surely the moving forward part means precisely that. Moving forward.

Please, re-read Carnuke's post courtesy of Debianus. Note the part about involving the community so that you all can focus on the code you love writing so much. So that the project (code and community) actually progresses in all directions at an advanced pace.

Crip

but in complement a Carnuke, remember it please.
Exist real good informations here.

"
Proposal for Xoops.org: New management structure
by skalpa on 2006/4/20 7:02:31

I feel extremely guilty. All this is, in a way, the consequence of my inability to act correctly. The consequence of wrong choices, my failure to this community I am supposed to be devoted to. By staying silent, so long, retreating in front of conflicts instead of being able to face them, I have harmed everybody, and I feel bad.

So I am happy to see that things become public, at last. But if that happens, I cannot accept to hear lies and disinformation, to see people manipulated, once more. We cannot talk about my attempt to build this council without talking about the motivation I had when creating it, its failure, and the reasons behind it.
Thus, here are a little more details:

The event that made me summon this council 3 months ago, was the answer made to Marco's attempts to contribute to this project: his corrections on the "XOOPS organization" page were removed "because they were negatively affecting the planned xoops.org reorganisation" (or something like this). But worst, the great roadmap draft he had prepared for the project, extracting short term or middle term issues was completely dissupported... paralelly the only enhancement the "Project Manager" had in mind to change things, was to replace a private mailing-list by a private website.

Things were, for me, going in the exact opposite direction as the one they should: in an open-source project, any management entity whatever form it takes (a single person or a group) is not here to take decisions but for monitoring purposes: to ensure the project will show support to individual initiatives that are positive for it, and advise existing teams so they work in a way that will generate success (an open ecosystem is very fragile, and without taking care of some specific aspects, will not work).

The people that were called, "to help taking the load of the management charges" were phppp and I (the 2 lead developers), jmorris (lead moderator on xoops.org and in charge of the servers administration), jdseymour (liaisons team) and Herko (actual lonely project manager and in charge of the "corporate communication" aspect).

This last person took this initiative extremely negatively. Several of his posts on the council site ended with sarcastic "But hey I am just the marketing & communications guy now", expressing his disliking of not being the person in control of everything anymore. And, even if I consider I may have misinterpreted these sentences, his bad will shown in other places leaded less place to interpretation.

The first point phppp and I have asked this council to take care of, was to deal with the 2.2 problem there was at that time. To clarify a few things: 2.2 is, technically speaking, a two years leap backward for XOOPS. It is not only a lot slower, but its architecture has also been greatly damaged in a way that makes it impossible to fix entirely. Some things can be corrected, but for others the only choice it let us was:
- To let things as-is, and forget XOOPS was once a lot more scalable
- To apply a "fix" that would in fact break 2.2 modules
This is why I had to take the hard decision not to use its code for the development of the next versions, and decided to call this branch "unstable" again, to limit its diffusion and the development of too many 2.2 modules that would necessarily need to be modified to work with future releases. The problem is that during the release of 2.2.4, it became advertised as "stable" again, without phppp's agreement nor mine.

Because of this, we were both considering this as an urgent issue, for the sake of the XOOPS users. This was delayed endlessly, Herko taking 2 weeks to add a couple sentences to the document I had sent him, as he thought it would have been better for "our image" to let 2.2 as it was, than to make the demanded change (btw: I saw the word accountability in this thread. Is to lie and hide the truth in a way harmful to the community to hide one of your, or your friend's mistake what accountability is about ?)

After this, the second thing we tried to do was to give a little life back to this project, make things move. What was proposed was to re-open the documentation site, at least with only the old documents to begin with.

Both Madfish and Rowd had shown their intention or even started to do something so we wanted to support them, and if necessary help them find the best methodology to make this attempt to revive the documentation successfull (a few ideas were launched: I talked about telling them to ensure they work publicly and make mini-roadmaps to go forward step by step, while jdseymour talked about using a wiki to ease collective writing). Again, the former project manager was opposed to this, saying that was needed first was to "define the role of the documentation in the project development" (whatever that means ?). I was strongly discouraged. And that went even worse, when I saw one week after in a thread called "A matter of priority... help docs" the exact same person answer to the community people who were complaining about the absence of documentation that "re-opening this site was on top of his to-do list" (sic).

Then I got really sick. This put an end to my participation to this council, as what I was observing had very bad consequences on my overall motivation: I stopped communicating, and had serious difficulties to start working on the code again for some time.

Because of all this, I have some real difficulties to believe that there is any kind of sincerity behind the proposal posted here. Specially when I observe the strange change of semantics between this post and the original one posted internally. The introduction to this proposal, that has become here:
Quote:



I've realised for a long time now that I am not competent and available enough to manage the whole project by myself




was originally this one:
Quote:



So, there's 2 ways to deal with this.
1. I quit. It's enough, I've given 3 years of my life for this, and this is how I get paid. Not just by the unwitting community (hervet and marco should know better by now, but they only listen to what they want to hear), but by those that are close to me too, like skalpa. I've run out of ideas to keep everyone happy, and leave the #OOPS# for someone else to clean up. I don't really care who it'll be. Yes, I am angry, and disappointed. SO be it.

2. I retake the leadership role. But this time we'll do it my way, with some ideas borrowed from this so called management council.
We'll make 2 major changes: reduce the number of members of the Foundation Board ..........




So, honnestly: I don't believe in this. Marco, and several others, tried to help. This council was here to help. But there is no way anything can be done, unless the order comes from the same person. At best, you'll just be ignored. At worse, you'll just see this person come back with the idea you had, a little later. Here, letting people help means letting them take care of specific tasks, not have them execute what was centrally decided.

To me, this just looks like the beginning of a political campaign of a politician trying to manipulate people, to attract the compassion of this community, in the hope of being elected soon, to gain a legitimity his positive contributions didn't give him.


So, now to switch to something more constructive and positive, and give you some ideas quickly:

1) Elections are not a good way to create an open-source social organisation. Democracy is good on paper, but the most emblematic achievement of democracy is the biggest corporation in the world, that created two of the richest people of this planet: a company called Microsoft. And open-source is a reaction to this. Elections rarely see the success of the "best" candidate, but of the people ambitious, of the politicians.
2) Open-source projects are more like meritocracies: you get your place according to what you offer for the best of the project, to how positive you act.
3) OSS should be completely modular, decentralized to the extreme. No central entity should make decisions for others. Devs decide about the code, writers about the documentation, moderators about the forum, people managing the extensions repository about how it can be enhanced, and so on... this is a key element. As it has been said, XOOPS is already too big to be centrally managed, and I hope it will become "even worse".
4) The two last points are strongly inter-related. 3) cannot work if you don't respect 2)
5) OSS is a contributive method. This means that people don't collaborate like this, they try to enhance something already existing (there's a real difference). For people to contribute you have to give them something, before everything. You cannot ask a community to do something from scratch.
6) To push decentralization even more, every part of the project should in itself be as modular as possible: everything you do should be made of smaller parts, as independent as possible from the other ones (this is the main thing that limited contribution to the code IMO, and what I tried to fix first).
7) EVERYTHING should be made publicly.
8) Positive contributions are always welcome. If you don't stay open enough, people will leave.
9) Roadmaps are here to tell people about what a "local" team intends to do in the near future. This way potential contributors can know how they would be able to help (that doesn't mean they will do, but it shouldn't prevent you from making one).
10) If management entity there is, it should only be here for monitoring: open the project even more, advise people, ensure the methodology is respected to prevent failure.
11) What makes XOOPS XOOPS is not the way it is managed (well, yes, but that's not really positive) it is the people who are forming its community.

To finish here: considering how it has been difficult to contribute lately, trying to get this project out of the current situation is very tricky. Now, there are people who have managed to keep XOOPS alive, who have always been the heart of XOOPS: local communities. According to the 2) rule, the people who manage these local communities should be the ones to be offered the possibility to resurrect this project. To ensure people can contribute to as many things as possible, actions has to be taken, quick. No need for a council wondering what it should be here for. Priority should be put on splitting things as much as possible (starting by this website), then there will be a way to form workgroups to enhance the different parts.

Those people are in my opinion the ones that deserve to get the entire community trust.
"

Note please " .... "

Look, good idea and reflexons too. Yes, problems here is actual (ainda)

To reflect, not to judge, not to condemn, they only ponder everything that occurs.

Original topic 116

Giba wrote
Quote:

Yes, many good points indeed. Particularly:

Quote:

Crip

well, we will have to resume that a little bit
let's create our own manifest !

up !
could some give their feedback.
i think its mandatory to start first to write our light manifest, before any other action. The step by step approach is always the best.
catz has some nice inputs too in his last post

marco, thanks for the excellent work.
The XOOPS is now moving forward step by step, and I would expect some efforts will be done on a manifest in the coming weeks, or even days.