[Ambassadors] Red Hat's investments (was Re: Going passive)

["Jóhann B. Guðmundsson"]

On 11/10/2010 11:23 PM, Jesse Keating wrote:
> On 11/10/10 3:02 PM, "Jóhann B. Guðmundsson" wrote:
>> This is something FPC or FESCO needs to deal with..
>>
>> They could make the decision that packagers need to at least show that
>> they have their own bugzilla account and are part of or in good
>> communication with the upstream community before they get their package
>> accepted in Fedora?
> You have to have an account before you can own a package.
>

I think you misunderstood me here I was referring to upstream bugzilla 
account.
( so atleast they could forward it there make reference to upstream bug 
on the report in our bugzilla )

>> Maintainers stop being so possessive about their components and reach
>> out and help each other out? ( better collaboration between maintainers )
> If a maintainer is too overloaded to fix their own packages, how can
> they have time to fix somebody else's packages?  Not to say that there
> isn't room for improvement in this area, I just don't see it as a long
> term solution.

hum...

let me lay it out one possible long term solution in one rough possible 
way.

1. Improve the general standard of packagers ( need to at least have 
upstream bugzilla account and are part of or in good communication with 
the upstream community )
2  Allow for a adjusting period when it's over revoke the rights from 
those that already have but do not full fill this requirements. Package 
goes up for grabs or gets dropped.
2. Allow all maintainers to touch every component in Fedora note that 
maintainer that brought the component to Fedora is still responsible for 
his components.
3. Gather what information from all those maintainers we have in the 
community what their code skill are and in which language and what skill 
level their expertise is.
4. Assemble a "bug fixing task force" ( can be per language ) to target 
component ( including testers if needed ).
5. Assign a component to the "bug fixing task force" and assign a time 
period they should spend looking at the bugs on that component and 
fixing them could be a day a week a month starting from critical path 
and onwards.
6. Assign interns ( students home hackers and what not ) to tag along 
the bug fixing task force and learn a few things..

Note that there could be several bug fixing task force working at the 
same time but in different programming language and based on what skill 
level they have as newbies could take the first rounds tackle the easy 
fixers push what they cant fix to the medium team which then goes 
through it if they cant handle it they push it on to the heavy hitters 
who will strike upon it with furious vengeance and squash that bug to a 
different dimension..

JBG