[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Draft guidelines for approving provenpackager

On Sat, 24 Jan 2009, Jesse Keating wrote:
> We don't currently have guidelines for granting access to proven
> packager.  I took a work item from FESCo to create a draft for this, and
> here is my first stab at it (words in camelcase exist to be replaced
> with links to pages concerning them):

Some time ago, I had a discussion with Kevin and Jason - but I'm not really
sure currently, as it already was late night. Maybe somebody can correct me
here if, I'm wrong.

Well, I was unhappy about the uberpackager/provenpackager situation and
that it is too easy to get this status. Ideas resulting of the discussion
has been, that uberpackagers/provenpackagers more should be some kind of
mentors and to help packagers when needed and requested. Yes, that's more
or less currently already case, but I had more the mentor thing in mind.

Uberpackagers/provenpackagers should be persons well known to the community
and having some presence at packagers. So a person only having 5 packages
gets a uberpackager/provenpackager, something really goes wrong IMHO. Yes,
we've changed that, but we should not make the status depend on packages or
some time at all, but on presence and knowledge of the person.

The other thing is, which is much more important, that not a single person
can sponsor a uberpackager/provenpackager. I was thinking about some kind
of "voting". Of course not a voting that kind, that all current sponsors
are getting notified via e-mail, but the possibility, that every sponsor
can add +1/0/-1 in FAS to a guy wanting to get uberpackager/provenpackager.
And if "charma" of that candidate is +5 or +10 in the end, the guy gets
uberpackager/provenpackager. If a sponsor is doing nothing, it's just +0/
-0, but the sponsors should not get bothered about each request of a new

Anyway for that we IMHO must reset the current uberpackager/provenpackager
list and restart with an empty one. Otherwise that doesn't make sense to me
and it doesn't change nor solve our problems we introduced in the past...


Attachment: pgpTKP2xPBLGS.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]