On 11/22/2011 06:46 PM, Kevin Fenzi wrote:
On Tue, 22 Nov 2011 17:51:31 +0000
"Jóhann B. Guðmundsson"<johannbg(a)gmail.com> wrote:
> What do people see as pros and cons continuing to use the current
> package ownership model?
>
> Would it be practical to dropping it altogether which in essence
> would make every contributor an "proven packager"?
I'm not sure it would be.
> Would it be viable to move to something like language SIG based
> ownership of packages?
Well, if we did that we would need to revamp SIGs I suppose.
We would need to make sure that there was some kind of SIG that covered
all packages so people would know who to talk with. Also, currently
some SIGs are very active and some really aren't at all. Also, a number
of SIGs overlap.
Yup moving to SIG based/Group ownership based approach would certainly
require revamping their current status.
> As in lower the barrier of entry of contributor without the need and
> or introduction of an package or any sponsorship and have them
> assigned to relevant SIG based on language they either know or want
> to learn. ( not necessarly having to tie packaging with code
> contribution ).
One thing thats worth noting here is:
http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_grou...
As another avenue to becoming a packager.
Cant these things to be separately completely as in the requirement to
become "packager" to be able to contribute to a package and the need for
sponsor ship be dropped in the process.
Atleast the one way as I see it is to move the SIG/Group based
ownerships of components anykind of barrier of entry would be removed
for participation and if/when the SIG/Group deems the individual ready
it will handle granting him any permissions the individual might lack
over the packages they oversee.
> The governing body of the SIG would in essence be the once that would
> be responsible for the components.
>
> So as an example a indvidual skilled in Java who would want to join
> the project would automatically be assigned to the java SIG which in
> turn would be assigned and managing all Java related components then
> the Java SIG based on what ever process/workflow they have decided
> would assign to that individual what ever task is needed at current
> times prioritized by the knowledge and resource they posses.
>
> So basically the barrier of entry is no higher than what the
> individual wants to learn or knows already as in..
>
> Do you know or want to learn python. Join the python SIG etc...
>
> Do you want to learn distribution packaging join the Packaging SIG
Good example. How do we handle overlaps here? Y
Would we need to as in would not an individual be able to participate in
as many SIG's/Groups as he wants too?
Someone wishes to help with general packaging things, so they need
to
update the java package guidelines and fix those packages. Do they join
the Packaging SIG? Java sig? both?
Yeah why not joining both however he ofcourse would need to follow
anykind of packaging standards the Java SIG ( Or any SIG/Group he might
be a part of ) would have should that package be overseed by the Java
SiG ( Or any relevant SIG/Group he might be a part of ),
> Or the individual would learn how to package components relevant
to
> the SIG he just joined
>
> Thoughts?
>
> Far off and totally crazy, you are mad!
>
> What meds are you on can I have some?
>
> The SIG approach is something that actually might work...
I'm not convinced it would, without changing how our sigs are setup.
That ofcourse might need some rethinking.
JBG