Re: Regrouping PEAR
| From: | Craig Constantine | Date: | Wed, 27 Sep 2006 19:56:34 +0000 |
| Subject: | Re: Regrouping PEAR | ||
| References: | 1 2 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-44114@lists.php.net to get a copy of this message | ||
--On September 27, 2006 9:24:39 PM +0200 Arnaud Limbourg
<arnaud@limbourg.com> wrote:
>> The Administrative Document for the PEAR Group says that only PEAR Group
>> members can change the members of the group. Can the Group members
>> please take it amongst themselves to fill these positions or defer to an
>> RFC that will repopulate the group?
>
> Another choice could be to have groups of packages with a bunch of people
> managing the group.
>
> Arnaud.
I think that would be logical.
Could we do it organically by having the package maintainers (or perhaps
everyone) vote the packages into groups. (As opposed to trying to RFC the
packages into groups.)
Dreaming out loud (ignoring implementation labors for the moment):
- We create a new "Package Group web interface" where any *package
maintainer* can (*can*, but is not required to) create a new group.
Creating a new group makes the package maintainer a member of the group.
Yes, a boring group-of-one person with no packages in it. (yet.)
- Add controls to package management for maintainers to "submit" their
package to the group. The group leaders (each group has just one leader
initially) then votes to accept the package. (So i've created a group for
my package, and now I can submit my package. Being the only member of the
package group, I can also vote my package in. Yawn.)
- Other maintainers can then decide to either do nothing. Make their own
package groups, or submit their package to an existing group. If package
"B"'s maintainer submits the package to the group, and I accept it; now
there are two group members and we have to vote/agree on future package
acceptance to the group.
- We keep all the group memebership (what packages in what groups, what
people in what groups) visible (to all with pear web accounts.) We keep all
the discussion in pear-dev (perhaps we allow plus-ed addressing to the
pear-dev list or something.
- Once we have some organization grown organically, we see if the package
group (the maintainers, the people) can take on any efforts, or at least we
can mentally weigh their opinions a little higher.
thoughts?
-c