12:54 a.m.
Hello all,
This charter corrects all of the known deficiencies from the last draft,
and additionally clarifies:
- that an email to adelie-project@ is required to propose a new Project;
- what happens when a Platform Group results in a tie;
- and shuffles the ordering of sections to be more logical.
Please review the entire document, and reply to this thread with any
comments, questions, or concerns you may have. Final voting on this
proposal remains set for this Friday, the 5th of April.
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
noon
On Mon, Apr 01, 2019 at 11:54:39PM -0500, A. Wilcox wrote:
Projects
========
For the purposes of this document, a Committer is a contributor to
Adélie Linux
that has write access to packages.git.
s/that/who/ perhaps?
Projects will be granted a Web space for any documentation they feel
appropriate. All Projects will be required to maintain a list of Committers
involved in the Project on this Web space. Projects may additionally maintain
a list of frequent non-Committer contributors as well, but they are not
required to do so.
The last sentence seems like unneccessary noise to me.
Creating a Project
------------------
A Project may be proposed for creation at any time by a Committer, via sending
an email to the adelie-project@ mailing list. This proposal must be approved
by a simple majority of the Platform Group.
"Committers may propose the creation of a Project with an email to
adelie-project@. This proposal then requires approval by a simple
majority of the Platform Group."
Disbanding a Project
--------------------
When a Project is disbanded, its mailing list must be made read-only, but its
archives must not be destroyed.
s/, .*/and the archives [must be] retained./ (Sounds better to me that
way, but either version is fine.)
The Platform Group may decide whether to archive or destroy the
Project's Web space. In the event of destruction, URLs must be set to
return a '410 Gone' response.
The 2nd sentence is an unneccessary technical detail, and it precludes
setting up a redirect, even though that may make more sense in some
cases.
Interest Groups
===============
Interest Groups will be granted Web space for any documentation they
feel
appropriate. Interest Groups, like Projects, shall maintain a list of
Committers on this Web space. They may, additionally, list non-Committer
regular contributors, though this is not required.
Last sentence: As above.
Platform Group
==============
This charter, as with most of the Adélie Linux system, depends heavily on a
functional Platform Group, which acts as the "root" of the structure. As
such,
a formal declaration of the Platform Group's responsibilities are listed in
this section. Additionally, addition and removal of members of the Platform
Group are discussed.
Questionable grammar in the middle sentence. Either s/are listed/is
given/ or s/a formal declaration of //.
Removal
-------
Expulsion of a member of the Platform Group may be initiated by either the
Platform Group itself, or a member of Community Arbitration.
"by any member of the PG or ComArb"; the current wording leaves unclear
how many PG members are required to initiate the process.
All members of the Platform Group vote except the member being
expelled. A
three-fourths majority of members must approve the expulsion. If less than
four members of the Platform Group remain to vote, then the largest possible
supermajority is required to approve the expulsion.
Before the vote, the member being expelled should be granted the
opportunity to make a statement. It might also be a good idea to enforce
a few days of delay to avoid rash decisions. I think the affected member
should be barred from voting altogether until the expulsion process has
concluded, to prevent them from casting purposefully disruptive votes
on other matters. (This creates an obvious DOS opportunity though.)
Voting
------
In the event of a Platform Group vote resulting in a tie, the vote of the
current Project Lead will be carried. If the Project Lead is absent, the vote
of the senior-most present member of the Platform Group will be carried.
Thanks for this change, I like it much better this way. Which type of
seniority is meant here, though? Time as a Committer or time as a PG
member (or perhaps even biological age :P )?
Cheers,
Luis
9:24 p.m.
On Apr 01 11:54 PM, A. Wilcox wrote:
Our first act in this charter is to define "Projects". A
Project is a
collective of contributors working towards a common goal. This goal should be
on-going and clearly defined (see Interest Groups below for one-time tasks).
At least one Committer is required to form a Project.
For projects which are completely orthogonal to packaging, is there
another requirement that could be used instead? For example,
documentation projects need write access to other git repositories, but
not necessarily packages.git.
The Project proposal must contain the name of the project, the
desired short
name for the mailing list, and the common goal it wishes to achieve.
It may be useful to add a requirement here to list the project's initial
members.
Disbanding a Project
--------------------
A Project may be disbanded without Platform Group interference if all
Committers assigned to the Project wish it so.
The Platform Group may disband a project with a three-fourths majority.
When a Project is disbanded, its mailing list must be made read-only, but its
archives must not be destroyed. The Platform Group may decide whether to
archive or destroy the Project's Web space. In the event of destruction, URLs
must be set to return a '410 Gone' response.
What happens in the event of the Platform Group disbanding?
Additionally, project web spaces should probably be preserved unless it
causes an undue burden on storage resources.
Interest Groups will be granted Web space for any documentation they
feel
appropriate. Interest Groups, like Projects, shall maintain a list of
Committers on this Web space. They may, additionally, list non-Committer
regular contributors, though this is not required.
How is an interest group formed? Is there a formal process for this?
Perhaps similar to that for projects, or maybe they can be formed ad
hoc.
The Platform Group handles addition and removal of Committers.
By what process are committers inducted? I believe this is documented
elsewhere, but it may be beneficial to include here.
If the Platform Group does not approve the expulsion, it may be
overridden by a
complete approval of the expulsion by every Committer.
I understand the high bar set here for overriding a failed platform
group member expulsion, but obtaining the approval of every single
committer seems a little impractical. I'm not sure what to suggest
however. In this event ComArb should probably be involved as well,
unless they initiated the proposal? As discussed on IRC it would
probably also help to clarify that members of ComArb cannot also be
members of the Platform Group.
In the event of a Platform Group vote resulting in a tie, the vote of
the
current Project Lead will be carried. If the Project Lead is absent, the vote
of the senior-most present member of the Platform Group will be carried.
There is currently no definition of "Project Lead" in this document.
Less importantly there is no definition of "senior-most" nor
"present"
member.
Overall however I agree with this proposal in the general sense, it just
needs clarification on the above points.
Max
3:37 p.m.
On 04/06/19 20:24, Max Rees wrote:
On Apr 01 11:54 PM, A. Wilcox wrote:
> Our first act in this charter is to define "Projects". A Project
> is a collective of contributors working towards a common goal.
> This goal should be on-going and clearly defined (see Interest
> Groups below for one-time tasks). At least one Committer is
> required to form a Project.
For projects which are completely orthogonal to packaging, is there
another requirement that could be used instead? For example,
documentation projects need write access to other git repositories,
but not necessarily packages.git.
A Committer is someone who has write access to at least one repository.
(That could even be Shimmy or gcompat.)
> The Project proposal must contain the name of the project, the
> desired short name for the mailing list, and the common goal it
> wishes to achieve.
It may be useful to add a requirement here to list the project's
initial members.
I was a bit leery of this because I didn't want people to be maliciously
added. Consider mailing lists; they require a confirmation email before
being subscribed.
I was going to add something like: "It may additionally include a list
of initial contributors, which will be contacted to ensure their desired
participation." But that adds more work for the Platform Group. Of
course, if we're letting the project define their members, maybe that
could happen anyway... unless we take subscription to the project's ML
as an implicit desire to join.
This should probably be discussed further, either here or IRC.
> Disbanding a Project
> --------------------
>
> A Project may be disbanded without Platform Group interference if
> all Committers assigned to the Project wish it so.
>
> The Platform Group may disband a project with a three-fourths
> majority.
>
> When a Project is disbanded, its mailing list must be made
> read-only, but its archives must not be destroyed. The Platform
> Group may decide whether to archive or destroy the Project's Web
> space. In the event of destruction, URLs must be set to return a
> '410 Gone' response.
What happens in the event of the Platform Group disbanding?
Additionally, project web spaces should probably be preserved unless
it causes an undue burden on storage resources.
Maybe it should be made explicit that the Platform Group cannot be
disbanded since that would be the end of Adélie (and should probably be
done more formally than disbanding the Platform Group).
The Platform Group decides whether to archive or destroy the Web space.
I can't imagine a case where we would want to destroy it unless it was
not in line with our code of conduct.
> Interest Groups will be granted Web space for any documentation
> they feel appropriate. Interest Groups, like Projects, shall
> maintain a list of Committers on this Web space. They may,
> additionally, list non-Committer regular contributors, though this
> is not required.
How is an interest group formed? Is there a formal process for this?
Perhaps similar to that for projects, or maybe they can be formed ad
hoc.
This was never agreed upon. Suggestions are welcome; I'd prefer it to
be more ad-hoc than the formal Project requests.
> The Platform Group handles addition and removal of Committers.
By what process are committers inducted? I believe this is
documented elsewhere, but it may be beneficial to include here.
An explicit link to that should be included, but I don't think the
organisational structure is an appropriate place to put that. Mostly
because we may want to amend those processes while we continue to grow,
and I don't think we should be amending this charter often.
> If the Platform Group does not approve the expulsion, it may be
> overridden by a complete approval of the expulsion by every
> Committer.
I understand the high bar set here for overriding a failed platform
group member expulsion, but obtaining the approval of every single
committer seems a little impractical. I'm not sure what to suggest
however. In this event ComArb should probably be involved as well,
unless they initiated the proposal? As discussed on IRC it would
probably also help to clarify that members of ComArb cannot also be
members of the Platform Group.
90%? Anything short of "every Committer" is going to be arbitrary.
Added the note about ComArb =/= PG.
> In the event of a Platform Group vote resulting in a tie, the
vote
> of the current Project Lead will be carried. If the Project Lead
> is absent, the vote of the senior-most present member of the
> Platform Group will be carried.
There is currently no definition of "Project Lead" in this document.
Less importantly there is no definition of "senior-most" nor
"present" member.
Overall however I agree with this proposal in the general sense, it
just needs clarification on the above points.
Max
I'm very unsure of how to define "Project Lead". I've added a
definition of seniority and clarified presence.
The new version of the charter will be sent to the list after these
issues and the other issues raised in this thread have been handled.
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
3:47 p.m.
On 04/03/19 11:00, Luis Ressel wrote:
On Mon, Apr 01, 2019 at 11:54:39PM -0500, A. Wilcox wrote:
> Projects
> ========
> For the purposes of this document, a Committer is a contributor to
> Adélie Linux that has write access to packages.git.
s/that/who/ perhaps?
Fixed, thank you.
> Projects will be granted a Web space for any documentation they
> feel appropriate. All Projects will be required to maintain a list
> of Committers involved in the Project on this Web space. Projects
> may additionally maintain a list of frequent non-Committer
> contributors as well, but they are not required to do so.
The last sentence seems like unneccessary noise to me.
The intent is that regular contributors to a Project that are not
Committers may still be recognised on the project's contributor list.
For example, maybe upstream KDE or MATE or LXQt developers may
contribute to the respective Adélie desktop project some day. We could
list them, if they want to be listed. But it is not a requirement.
> Creating a Project
> ------------------
>
> A Project may be proposed for creation at any time by a Committer,
> via sending an email to the adelie-project@ mailing list. This
> proposal must be approved by a simple majority of the Platform
> Group.
"Committers may propose the creation of a Project with an email to
adelie-project@. This proposal then requires approval by a simple
majority of the Platform Group."
I'm happier with the way it is worded in the charter. Is there a
specific issue you have with it?
> Disbanding a Project>> --------------------
> When a Project is
> disbanded, its mailing list must be made read-only, but its
> archives must not be destroyed.
s/, .*/and the archives [must be] retained./ (Sounds better to me
that way, but either version is fine.)
Fixed, thank you.
> The Platform Group may decide whether to archive or destroy the
> Project's Web space. In the event of destruction, URLs must be set
> to return a '410 Gone' response.
The 2nd sentence is an unneccessary technical detail, and it
precludes setting up a redirect, even though that may make more sense
in some cases.
The resource being requested (Web space associated with that Project)
has been permanently removed at this point. Redirects can do a lot of
damage and are almost never helpful to users that want to read the
documentation that was present before. (Looking at you, Fedora wiki.)
> Interest Groups
> ===============
> Interest Groups will be granted Web space for any documentation
> they feel appropriate. Interest Groups, like Projects, shall
> maintain a list of Committers on this Web space. They may,
> additionally, list non-Committer regular contributors, though this
> is not required.
Last sentence: As above.
> Platform Group>> ==============
>
> This charter, as with most of the Adélie Linux system, depends
> heavily on a functional Platform Group, which acts as the "root" of
> the structure. As such, a formal declaration of the Platform
> Group's responsibilities are listed in this section. Additionally,
> addition and removal of members of the Platform Group are
> discussed.
Questionable grammar in the middle sentence. Either s/are listed/is
given/ or s/a formal declaration of //.
Went with "is provided". Thank you.
> Removal
> -------
>
> Expulsion of a member of the Platform Group may be initiated by
> either the Platform Group itself, or a member of Community
> Arbitration.
"by any member of the PG or ComArb"; the current wording leaves
unclear how many PG members are required to initiate the process.
Fixed, thank you.
> All members of the Platform Group vote except the member being
> expelled. A three-fourths majority of members must approve the
> expulsion. If less than four members of the Platform Group remain
> to vote, then the largest possible supermajority is required to
> approve the expulsion.
Before the vote, the member being expelled should be granted the
opportunity to make a statement. It might also be a good idea to
enforce a few days of delay to avoid rash decisions. I think the
affected member should be barred from voting altogether until the
expulsion process has concluded, to prevent them from casting
purposefully disruptive votes on other matters. (This creates an
obvious DOS opportunity though.)
How is this?
A vote on whether to expel the member must be held at least 48 hours
after the explusion announcement, to avoid emotionally charged voting.
During this time, the member may make a statement if they desire to do so.
> Voting
> ------
>
> In the event of a Platform Group vote resulting in a tie, the vote
> of the current Project Lead will be carried. If the Project Lead
> is absent, the vote of the senior-most present member of the
> Platform Group will be carried.
Thanks for this change, I like it much better this way. Which type
of seniority is meant here, though? Time as a Committer or time as a
PG member (or perhaps even biological age :P )?
Time as a PG member; this has been clarified.
Cheers, Luis
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
5:09 p.m.
On Thu, Apr 11, 2019 at 02:47:31PM -0500, A. Wilcox wrote:
On 04/03/19 11:00, Luis Ressel wrote:
> On Mon, Apr 01, 2019 at 11:54:39PM -0500, A. Wilcox wrote:
>
>> Creating a Project
>> ------------------
>>
>> A Project may be proposed for creation at any time by a Committer,
>> via sending an email to the adelie-project@ mailing list. This
>> proposal must be approved by a simple majority of the Platform
>> Group.
>
> "Committers may propose the creation of a Project with an email to
> adelie-project@. This proposal then requires approval by a simple
> majority of the Platform Group."
I'm happier with the way it is worded in the charter. Is there a
specific issue you have with it?
The current wording just has a slightly awkward flow (IMO). But you're
the native speaker, not me. :)
>> All members of the Platform Group vote except the member
being
>> expelled. A three-fourths majority of members must approve the
>> expulsion. If less than four members of the Platform Group remain
>> to vote, then the largest possible supermajority is required to
>> approve the expulsion.
>
> Before the vote, the member being expelled should be granted the
> opportunity to make a statement. It might also be a good idea to
> enforce a few days of delay to avoid rash decisions. I think the
> affected member should be barred from voting altogether until the
> expulsion process has concluded, to prevent them from casting
> purposefully disruptive votes on other matters. (This creates an
> obvious DOS opportunity though.)
How is this?
A vote on whether to expel the member must be held at least 48 hours
after the explusion announcement, to avoid emotionally charged voting.
During this time, the member may make a statement if they desire to do so.
Sounds great, save for the "explusion" typo.
--
Cheers, Luis
9:31 p.m.
On Apr 11 02:47 PM, A. Wilcox wrote:
On 04/03/19 11:00, Luis Ressel wrote:
> On Mon, Apr 01, 2019 at 11:54:39PM -0500, A. Wilcox wrote:
>> All members of the Platform Group vote except the member being
>> expelled. A three-fourths majority of members must approve the
>> expulsion. If less than four members of the Platform Group remain
>> to vote, then the largest possible supermajority is required to
>> approve the expulsion.
>
> Before the vote, the member being expelled should be granted the
> opportunity to make a statement. It might also be a good idea to
> enforce a few days of delay to avoid rash decisions. I think the
> affected member should be barred from voting altogether until the
> expulsion process has concluded, to prevent them from casting
> purposefully disruptive votes on other matters. (This creates an
> obvious DOS opportunity though.)
How is this?
A vote on whether to expel the member must be held at least 48 hours
after the explusion announcement, to avoid emotionally charged voting.
During this time, the member may make a statement if they desire to do so.
+1
Max
10:18 p.m.
On Apr 11 02:37 PM, A. Wilcox wrote:
On 04/06/19 20:24, Max Rees wrote:
> For projects which are completely orthogonal to packaging, is there
> another requirement that could be used instead? For example,
> documentation projects need write access to other git repositories,
> but not necessarily packages.git.
A Committer is someone who has write access to at least one repository.
(That could even be Shimmy or gcompat.)
This contradicts the opening of the document:
"For the purposes of this document, a Committer is a contributor to
Adélie Linux that has write access to packages.git."
So that needs to be reconciled.
> It may be useful to add a requirement here to list the
project's
> initial members.
I was a bit leery of this because I didn't want people to be maliciously
added. Consider mailing lists; they require a confirmation email before
being subscribed.
I was going to add something like: "It may additionally include a list
of initial contributors, which will be contacted to ensure their desired
participation." But that adds more work for the Platform Group. Of
course, if we're letting the project define their members, maybe that
could happen anyway... unless we take subscription to the project's ML
as an implicit desire to join.
This should probably be discussed further, either here or IRC.
Optionally include an initial list of members, and those members can
reply to the proposal to affirm their support and desire to be included,
otherwise it is assumed they are not interested.
This raises another point however - how do people join a project after
the fact? If no list of members is given, then the project is formed
with a single member. Perhaps other members can join the project ad-hoc
later through whatever process that project decides upon (most likely
subscribing to its ML as you have said), or they need to be approved by
the PG. I'm not sure.
> What happens in the event of the Platform Group disbanding?
> Additionally, project web spaces should probably be preserved unless
> it causes an undue burden on storage resources.
Maybe it should be made explicit that the Platform Group cannot be
disbanded since that would be the end of Adélie (and should probably be
done more formally than disbanding the Platform Group).
I suppose. There are other possibilities here (such as giving the
Project Leader the discretion to dissolve the PG and call for
elections), but they complicate things further, so perhaps best to keep
it simple.
The Platform Group decides whether to archive or destroy the Web
space.
I can't imagine a case where we would want to destroy it unless it was
not in line with our code of conduct.
This part should be added to the document then, to make it clear that PG
would prefer not to remove project web spaces except for extenuating
circumstances.
> How is an interest group formed? Is there a formal process for
this?
> Perhaps similar to that for projects, or maybe they can be formed ad
> hoc.
This was never agreed upon. Suggestions are welcome; I'd prefer it to
be more ad-hoc than the formal Project requests.
Interest groups can be completely ad-hoc (formed at will by their
members). If they require web space etc. ("community resources") then
they can petition the PG on this mailing list. Otherwise they are on
their own. They can be disbanded at will by their own members like
Projects, or disbanded by the PG using the same process as with
Projects.
In this way the differences between interest groups and Projects are
thus:
* No proposal is needed to form an interest group. They can be formed
at-will by any members of the community. If the interest group would
like to solicit new members from the community at-large, they should
post to this mailing list.
* Community resources are not automatically allocated for an interest
group; they must be explicitly requested.
* Interest groups do not need to keep a formal list of members because
of the above. Therefore membership in an interest group is much more
lax than membership in a Project.
> By what process are committers inducted? I believe this is
> documented elsewhere, but it may be beneficial to include here.
An explicit link to that should be included, but I don't think the
organisational structure is an appropriate place to put that. Mostly
because we may want to amend those processes while we continue to grow,
and I don't think we should be amending this charter often.
A link is fine.
> I understand the high bar set here for overriding a failed
platform
> group member expulsion, but obtaining the approval of every single
> committer seems a little impractical. I'm not sure what to suggest
> however. In this event ComArb should probably be involved as well,
> unless they initiated the proposal? As discussed on IRC it would
> probably also help to clarify that members of ComArb cannot also be
> members of the Platform Group.
90%? Anything short of "every Committer" is going to be arbitrary.
Yes, this is the problem. Perhaps it would be easier to say "every
*active* Committer" must approve the expulsion in order to override the
PG, and we can give some arbitrary amount of time since last commit (to
any project) in order to achieve "active" status. To be sure, the commit
must have occurred before the initiation of the first expulsion proposal
so that nobody tries to game the system.
I'm very unsure of how to define "Project Lead".
I've added a
definition of seniority and clarified presence.
"The Project Lead is the leader of the Platform Group as well as the
community as a whole, and determines the direction and goals of Adélie
Linux. The primary faculty of the Project Lead is holding the
tiebreaking power over the Platform Group. The current Project Lead is
A. Wilcox, and at this time there is no formal process by which the
Project Lead can be changed or removed. In the event A. Wilcox is
removed from the Platform Group, the current Community Arbitrator will
temporarily assume tiebreaking power while the Platform Group amends
this document."
Essentially, you're our beloved BDFL.
Max
8:46 p.m.
On 04/11/19 16:09, Luis Ressel wrote:
Sounds great, save for the "explusion" typo.
Fox goes floof, PG member goes exploof.
(Fixed.)
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
7:57 p.m.
On 04/11/19 21:18, Max Rees wrote:
On Apr 11 02:37 PM, A. Wilcox wrote:
> On 04/06/19 20:24, Max Rees wrote:
>> For projects which are completely orthogonal to packaging, is there
>> another requirement that could be used instead? For example,
>> documentation projects need write access to other git repositories,
>> but not necessarily packages.git.
>
> A Committer is someone who has write access to at least one repository.
> (That could even be Shimmy or gcompat.)
This contradicts the opening of the document:
"For the purposes of this document, a Committer is a contributor to
Adélie Linux that has write access to packages.git."
So that needs to be reconciled.
Fixed in the latest draft.
>> It may be useful to add a requirement here to list the
project's
>> initial members.
>
> I was a bit leery of this because I didn't want people to be maliciously
> added. Consider mailing lists; they require a confirmation email before
> being subscribed.
>
> I was going to add something like: "It may additionally include a list
> of initial contributors, which will be contacted to ensure their desired
> participation." But that adds more work for the Platform Group. Of
> course, if we're letting the project define their members, maybe that
> could happen anyway... unless we take subscription to the project's ML
> as an implicit desire to join.
>
> This should probably be discussed further, either here or IRC.
Optionally include an initial list of members, and those members can
reply to the proposal to affirm their support and desire to be included,
otherwise it is assumed they are not interested.
This is also fixed in the latest draft.
This raises another point however - how do people join a project
after
the fact? If no list of members is given, then the project is formed
with a single member. Perhaps other members can join the project ad-hoc
later through whatever process that project decides upon (most likely
subscribing to its ML as you have said), or they need to be approved by
the PG. I'm not sure.
A suggested process has been added to the latest draft. The remaining
question is figuring out how expulsion from a Project works.
Half the Committers in the Project? Two Committers? etc.
>> What happens in the event of the Platform Group disbanding?
>> Additionally, project web spaces should probably be preserved unless
>> it causes an undue burden on storage resources.
>
> Maybe it should be made explicit that the Platform Group cannot be
> disbanded since that would be the end of Adélie (and should probably be
> done more formally than disbanding the Platform Group).
I suppose. There are other possibilities here (such as giving the
Project Leader the discretion to dissolve the PG and call for
elections), but they complicate things further, so perhaps best to keep
it simple.
A contingency plan for the instance of the Platform Group becoming empty
has been added to the latest draft.
> The Platform Group decides whether to archive or destroy the Web
space.
> I can't imagine a case where we would want to destroy it unless it was
> not in line with our code of conduct.
This part should be added to the document then, to make it clear that PG
would prefer not to remove project web spaces except for extenuating
circumstances.
Fixed in latest draft.
>> How is an interest group formed? Is there a formal process
for this?
>> Perhaps similar to that for projects, or maybe they can be formed ad
>> hoc.
>
> This was never agreed upon. Suggestions are welcome; I'd prefer it to
> be more ad-hoc than the formal Project requests.
Interest groups can be completely ad-hoc (formed at will by their
members). If they require web space etc. ("community resources") then
they can petition the PG on this mailing list. Otherwise they are on
their own. They can be disbanded at will by their own members like
Projects, or disbanded by the PG using the same process as with
Projects.
In this way the differences between interest groups and Projects are
thus:
* No proposal is needed to form an interest group. They can be formed
at-will by any members of the community. If the interest group would
like to solicit new members from the community at-large, they should
post to this mailing list.
* Community resources are not automatically allocated for an interest
group; they must be explicitly requested.
* Interest groups do not need to keep a formal list of members because
of the above. Therefore membership in an interest group is much more
lax than membership in a Project.
>> By what process are committers inducted? I believe this is
>> documented elsewhere, but it may be beneficial to include here.
>
> An explicit link to that should be included, but I don't think the
> organisational structure is an appropriate place to put that. Mostly
> because we may want to amend those processes while we continue to grow,
> and I don't think we should be amending this charter often.
A link is fine.
Reference added.
>> I understand the high bar set here for overriding a failed
platform
>> group member expulsion, but obtaining the approval of every single
>> committer seems a little impractical. I'm not sure what to suggest
>> however. In this event ComArb should probably be involved as well,
>> unless they initiated the proposal? As discussed on IRC it would
>> probably also help to clarify that members of ComArb cannot also be
>> members of the Platform Group.
>
> 90%? Anything short of "every Committer" is going to be arbitrary.
Yes, this is the problem. Perhaps it would be easier to say "every
*active* Committer" must approve the expulsion in order to override the
PG, and we can give some arbitrary amount of time since last commit (to
any project) in order to achieve "active" status. To be sure, the commit
must have occurred before the initiation of the first expulsion proposal
so that nobody tries to game the system.
I'll work on this and the IG stuff a bit later.
> I'm very unsure of how to define "Project Lead".
I've added a
> definition of seniority and clarified presence.
"The Project Lead is the leader of the Platform Group as well as the
community as a whole, and determines the direction and goals of Adélie
Linux. The primary faculty of the Project Lead is holding the
tiebreaking power over the Platform Group. The current Project Lead is
A. Wilcox, and at this time there is no formal process by which the
Project Lead can be changed or removed. In the event A. Wilcox is
removed from the Platform Group, the current Community Arbitrator will
temporarily assume tiebreaking power while the Platform Group amends
this document."
Essentially, you're our beloved BDFL.
Aww :) Added, with slight rewording.
After I take care of the interest groups and the PG expulsion methods,
I'll send a new draft to the list.
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
752
days inactive
770
days old
adelie-project@lists.adelielinux.org
9 comments
3 participants
participants (3)
-
A. Wilcox -
Luis Ressel -
Max Rees