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
Received on Fri Apr 12 2019 - 02:22:26 UTC