Re: [Speed-dreams-devel] R: The SD dev. rules

[Jean-Philippe <jpm...@fr...>]

Hi, Ocirne, all.

@all : Important question at the bottom, please think it again and vote.

Nice to get news :-)

> I'm sorry for having disappeared so long, but - as I wrote on
> PersonalPlansPost2.0 - I have been extremely busy for study and I'm afraid it's
> not over yet.

No problem, we know it, because you warned us. Perfect.
No more (apologise) needed. Just was the rules say :-)

> Today checked the email and found 800 unread messages from Speed
> Dreams lists;

That's a real issue for devs / contributors in your position
(forced to stay totally inactive for weeks or even months) ...
Any idea to make their life easier is welcome (call to all brains around ;-).

> lucky enough - the first one concerned review/agreement of the dev
> rules. I've found some time to enjoy reading them :-P, so here I'm officially
> accepting them with two only remarks:

Thanks !

> 1- I agree with defining the fields of expertise of the team members, but this
> shouldn't mean to forget that everyone could try/do (at least at a basic level)
> and most of all _learn_ """everything""" (I think this is important if we want
> to progress, because the team is still relatively small).

I agree. Was only lightly suggested in 
https://sourceforge.net/apps/trac/speed-dreams/wiki/RolesResponsibilities ; just 
added your sentence in this chapter : 
https://sourceforge.net/apps/trac/speed-dreams/wiki/RolesResponsibilities#Actualstructureoftheteam

> 2- Considering the struggles erupted because of the lack of rules, I agree it is
> vital to set them "crystal clear" and rigid (also to have clear policies about
> rigidity - i.e. changing the rules themselves).
> But I would like to point out the hazard of being smothered by an excess of
> rules: remember that rules are inanimate things, which are created by man for
> man's profit - not as an obstacle - and which are created in the present time,
> so they could become inadequate in the future even if nobody makes mistakes (we
> are not fortune-tellers). It's something which I have found also while studying
> Wikipedia's guidelines: the "Ignore all rules" policy. Not a subversive
> attitude, but an exhortation to common sense: more on
> http://en.wikipedia.org/wiki/Wikipedia:IAR and
> http://en.wikipedia.org/wiki/Wikipedia:IAR?.

I agree. These rules are here to find a compromise between the chaos
and an actually fun (for us) and productive (for our end-users) project.

And among them, there's a clear rule that states that the rules can change,
but not everyday : 
https://sourceforge.net/apps/trac/speed-dreams/wiki/ReleaseMethod#FuturechangesoftheReleaseMethod

So ... IIUC ... are you suggesting that the "two-thirds majority of the dev. 
team has to agree" rule is too much rigid ?

There was a discussion between I and Kristof (no more devs :-(,
where we we hesitating between the simple "majority" (half + 1)
and the 2/3 majority. And we agreed on the latter.
And everyone agreed (7+1 out of 9 active members for the moment).

As everything here (including the rules), let's discuss it :-)

What do you think all ?

Cheers,

Jean-Philippe.