From: Phil Blundell <pb@reciva.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: progress on OE organization issues
Date: Thu, 11 Jun 2009 11:10:57 +0100 [thread overview]
Message-ID: <1244715057.21585.87.camel@mill.internal.reciva.com> (raw)
In-Reply-To: <d2b9ea600906102348n6a220b46r1e5e5750863b72e@mail.gmail.com>
On Thu, 2009-06-11 at 08:48 +0200, Esben Haabendal wrote:
> According to the babelfish translation of the statues, only active
> members are given votes.
>
> I believe it is worth noting that thit ties in the current SCM architecture into
> the statues. If someone decided to use a more distributed approach (fx. using
> pull-requests instead of commit access), these rules would not give them
> voting rights. Any reason to involve SCM architecture into the statues?
There doesn't seem to be anything in the statutes which talks about
commit access specifically. According to the KDE translation of the
statutes, an active membership:
"will be granted if suggested by a member and supported by two other
active members, if the general meeting decides to grant it or if a
simple majority of the active members is obtained by means of an
internet vote. The main criterion for granting membership should be the
candidate’s commitment over a longer period of time and the
contributions he/she made in order to fulfil the Association’s aims".
and, allowing for the slightly garbled translation that you get out of
babelfish, the version on the oe wiki seems to be saying basically the
same thing. So I don't think there is anything to prevent a
non-committing supporter from becoming an active supporter and gaining
voting rights, so long as they undertake to further the e.V.'s aims in
some other way.
But, if the statutes really do talk about SCMs specifically in some
clause that I've overlooked, then I agree this is probably a mistake.
p.
next prev parent reply other threads:[~2009-06-11 10:20 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-30 12:44 progress on OE organization issues Cliff Brake
2009-04-30 14:26 ` Phil Blundell
2009-05-01 1:43 ` Cliff Brake
2009-05-07 11:19 ` Phil Blundell
2009-05-07 12:08 ` Philip Balister
2009-05-15 17:56 ` Phil Blundell
2009-05-15 19:04 ` Philip Balister
2009-05-15 21:54 ` Phil Blundell
2009-05-15 22:37 ` Michael 'Mickey' Lauer
2009-05-16 9:48 ` Richard Purdie
2009-05-16 10:55 ` Phil Blundell
2009-05-16 13:03 ` Mark Brown
2009-05-16 12:02 ` Phil Blundell
2009-05-16 12:54 ` Philip Balister
2009-06-02 21:18 ` Phil Blundell
2009-06-04 19:57 ` GNUtoo
2009-06-05 21:43 ` Cliff Brake
2009-06-06 6:46 ` Michael 'Mickey' Lauer
2009-06-09 9:21 ` Michael 'Mickey' Lauer
2009-06-09 9:53 ` Rolf Leggewie
2009-06-10 13:34 ` Cliff Brake
[not found] ` <d2b9ea600906092353o4fe9ea02vbc7df3b103b401c4@mail.gmail.com>
2009-06-10 13:11 ` Michael 'Mickey' Lauer
2009-06-11 6:48 ` Esben Haabendal
2009-06-11 10:10 ` Phil Blundell [this message]
2009-06-11 12:35 ` Philip Balister
2009-05-15 19:48 ` Cliff Brake
2009-05-24 15:49 ` Alessandro GARDICH
2009-05-24 16:26 ` Philip Balister
2009-05-06 12:44 ` Cliff Brake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1244715057.21585.87.camel@mill.internal.reciva.com \
--to=pb@reciva.com \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox