Request: please consider clarifying the project's position on Spins

[Jesse Keating]

On 12/03/2010 02:19 PM, Greg DeKoenigsberg wrote:
>> Greg, your reasoning here seems to assume that if you as a sig recruit
>> somebody to QA, that person would then start doing things unrelated to
>> your sig within the QA group.  That doesn't have to be the case.  Most
>> of the groups within Fedora are setup buffet style, each person picks
>> what it is they want to work on.  Being in the group gives them the
>> rights or status to accomplish the tasks, but they still pick which
>> tasks to work on.
>>
>> So if the KDE sig recruits some QA people or releng people, I don't see
>> any problem with those people only taking on KDE related QA/releng
>> tasks.  In fact, I would /expect/ that.
>>
>> We don't really assign tasks in Fedora groups, we just try to make it
>> easy for people to pick which tasks they want to work on.
>>
> 
> Put another way:
> 
> Joining a "Generic QA Group" to help with the QA of FooDE seems like
> unnecessary overhead, unless it's *very clear* what advantage joining that
> group confers.  It may well be easier to simply have the FooDE SIG hold
> their own meetings, build their own schedules, do their own QA, write their
> own release notes, and do their own marketing.  What clear value proposition
> is there to matrix this work across different SIGs/subprojects to the FooDE
> folks?  Because it's not clear to me, and it doesn't seem like it's clear to
> the folks who are working on the various Spins, either.
> 
> --g
> 

In the releng aspect, you'd be granted rights to push the buttons to
make images show up, and rights to be able to copy those images out to
our master mirror.

In QA it might be getting proper system rights to "approve" images
through the magical future QA test/results system.

In Art, it might be rights to upload new content to the upstream repos
and rebuild the packages downstream.

In all cases, it would be showing a commitment to come to the meetings
or read the lists and learn more about the group tasks, and help build
out documentation for the tasks related to the specific sig.

And unless we've gone off the rails, there is still a coordinated
release date of Fedora deliverables, and sigs would need to integrate
their work with these release dates.  So some level of "build their own
schedules" but those have to integrate with the rest of the project, and
what better way to do that then to participate in the central groups.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating