Is it possible for projects to be nested, possibly within multiple super-projects?
Like, for example, a project dealing with a gnome chat client itself being members of both the gnome and the chat projects (hypothetically speaking)? Maybe allow projects themselves to be members of other projects when needed. On Sat, Sep 19, 2015 at 3:26 PM, Rich Freeman <ri...@gentoo.org> wrote: > On Sat, Sep 19, 2015 at 5:07 PM, Daniel Campbell <z...@gentoo.org> wrote: > > +1 in general, but I'm a little pensive about allowing non-devs to > > become official project members. Becoming a developer can be a > > grueling process, so I understand that some don't have the time or > > motivation, and still want to help out. So perhaps we could have > > contributors who wish to be project members pass our ebuild test, or > > some other litmus test to prove themselves, like a developer proxying > > them or something. Non-devs don't have direct push permissions to our > > main repo, so to my knowledge they'd still have to go through a dev. > > I'd just like to see some sort of documentation that sets expectations > > for non-dev project members so that a new contributor understands what > > would be expected. > > I don't think that project member and commit access have to be > all-or-nothing together. > > I'd suggest leaving it up to each team to decide who is allowed to be > a member if they're a non-dev, and the rest are just contributor. The > team can use whatever rules seems best. > > Project members don't necessarily have formal powers, though typically > they participate in elections for the lead. > > As always, if there is trouble there is always comrel or council. I > think most teams should be able to figure out who should and shouldn't > be acknowledged as a member. > > But, there is still the GLEP 39 issue. I'd suggest the "contributor" > label for things like alias members until that is sorted out. There > isn't really much distinction in reality. > > -- > Rich > >
