With the 'proven' definition being repeated contributions, and explicit in the previous email the view AT's are lesser, but can move 'up' to the level of an ebuild dev, back to this email...
On Tue, Sep 13, 2005 at 04:14:34AM +0100, Ciaran McCreesh wrote: > On Mon, 12 Sep 2005 23:01:20 -0400 Alec Warner <[EMAIL PROTECTED]> > wrote: > | I'm not confusing anything here. Arch Devs ( ala members of arch > | teams ) and Arch testers should be equal in terms of developer > | status. > > Why? Arch testers *aren't* full developers. They may become them, but > they haven't yet demonstrated that they're capable of being a full > developer. Arch devs != ebuild devs != ATs They're different roles. Stop intermixing them, unless you're going to start throwing portage devs, doc devs, infra, and devrel in. There _is_ a common subset to portage devs, arch devs, ebuild devs, and ATs, but that does not mean they're equal in requirements and roles. Each has a role, don't blur the AT definition into ebuild devs unless you've after eliminating AT positions (something I doubt going by your previous QA threads); if you're after that, state so please. > | voting previleges > > Again, why? They have not yet demonstrated their understanding of > complex technical issues. Voting should be restricted to people who > know what they're doing. Arch testers have not yet proven themselves. Have doc devs demonstrated their understanding of complex technical issues? Portage devs? Infra? Your metric frankly is rather vague. Come up with one applicable to AT's rather then vague terms impying AT's are not of the 'elite' ebuild dev standard please. Additionally, Note that those proposing the glep utilize AT's in their arch; they may have a different view of role/ability of the AT's then you do, and of their abilities. IOW, nail down your metric, then apply it to the existing AT's (since they are what we have to work with), and then re-raise your views that they "don't know what they're doing". Back to the "complex technical issues", point I'm getting at is that the problem domain of both differ, even if they may have a common subset. > | > Assuming by "arch dev" you mean "arch tester", then: > | > > | > Experience, commitment and (at least in theory) recruitment > | > standards. > | > | Commitment first: > | IMNSHO, it is rude to assume that an Arch Tester is less commited to > | their work than an Arch Team member. All developers should be doing > | their part and should hopefully ( we don't live in an ideal world here > | after all ) be commited to doing their work well. A lack of > | commitment that results in shoddy work should get them removed from > | any developer role, Arch Team member or otherwise. > > An arch tester has not committed himself to the project for the same > length of time as a full developer. This is mild BS, since it's a common issue to all classes of gentoo volunteers. Further, stats provided (as were requested) I'd posit are actually better then ebuild dev stats, although worth noting the sampling period differs. > | Being a Gentoo developer isn't ( or I should say, shouldn't be ) all > | about what happens in CVS. There are many people who support other > | portions of gentoo forums/bugs/devrel/testing/user > | relations/gentooexperimental.org/etc and some sort of stupid elitism > | about being a "better dev" or a dev that has "better skillz" because > | said dev has commit access is simply stupid. Devs with commit access > | may be skilled in the workings of the tree ( and there are certainly > | devs with commit access that do not possess such a skillset ), but > | that should be why they have commit access, because they possess the > | skills to manage the tree. > > Uhm... Different people have different skill levels. Some of this is > down to natural ability, some of it is down to experience. Arch testers > have not yet proven themselves. Full developers have (at least in > theory...). Not much for the natural ability bit/elitist stuff; the question is what they've demonstrated, the work done. Doesn't matter if it takes a person 20 hours, or 1, it's the end product people see, and what ultimately matters (as you've pointed out in re: to QA). Beyond that, I don't agreew with the "Arch testers haven't proven themselves". They wouldn't be marked as AT's by the arch if they hadn't demonstrated some form of worth, just the same as ebuild devs aren't recruited if they haven't shown some form of worth (this includes ability to stick around for more then a month). Screwups happen, but the stats offered are a pretty good indication they've got that angle addressed imo. The only bit I'd actually disagree with on the glep is the 2 weeks period for conversion of an AT to an ebuild devs; the two roles (imo) are seperate, those handling ebuild devs should set the requirements themselves, just the same as those handling AT devs should set the requirements they perceive as needed. My 2 cents? They're doing work for gentoo. They may, or may not want to become ebuild devs (that being they're choice, and decided by those handling ebuild devs). Doesn't really matter, not everyone wants to be a pkg maintainer. Treating contributors as second class citizens (in terms of cvs ro access and email) is a really great way to piss on people who are doing a good chunk of work for gentoo. They *should* be provided better means of doing their work, and should be thrown the email addie as recognition for their contributions once they've met the common requirements of all gentoo personel (sticking around, contributing, etc). ~harring
pgpwdS15Jymfg.pgp
Description: PGP signature
