Re: Improvements of Fedora Sponsorship process

2016-08-08 Thread Jason L Tibbitts III
I wanted to elaborate on one of the ideas I threw out during that
discussion.

We (need to|should|strive really hard to) treat new packagers more like
new volunteers for fedora infrastructure.  Except that we should accept
that packaging is really, really hard when you don't know where to start
and offer more hand-holding.  The infrastructure process seems to work
really well (for infrastructure, at least) and the new packager process
seems to _not_ work really well, so

Note that I'm assuming here that we don't have that miraculous review
handling program (fresque).  I know someone was working on it, and I
should probably see what state it's in, but I'm way behind after being
on vacation for a month.  It wouldn't really alter the central point
anyway.

My random proposal for that is to:

1) Add more "front end" to the process (which, yeah, means more process
   when we already have too much process).  Packagers should send an
   introduction and such, perhaps even before they have a package.  They
   may need help doing that, after all, and we should be providing that
   help.
   
2) At some point, they should be assigned three (or some other
   reasonable number) mentors, including (if possible) one from the same
   region (from the ambassadors pool or one of the regional groups) just
   to help with language issues in case they come up.  These don't have
   to be sponsors, but at least two should be packagers.  Hopefully one
   is familiar with and has interest in the "type" of software they
   intend to package.  (Python, Java, games, whatnot.)

3) They should also be assigned a sponsor from the sponsor pool, if one
   is not part of the mentor group.  This person will oversee the
   process and actually give the permissions, though they don't
   necessarily have to do the heavy lifting.

3) These mentors should be "on hand" to assist the packager, answer
   questions, etc.

4) We should encourage that new packagers put their specs in pagure so
   that people can file pull requests against them.  Probably small
   specs for easy packages don't need this.  This conveniently gives
   them a base to have copr pull from, assuming I understand that
   functionality of copr.  They'll still have to post updates to
   bugzilla but we might be able to automate that.

5) A whole bunch more automation to get packages checked and people
   pinged would of course be quite useful here.

 - J<
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


Re: Improvements of Fedora Sponsorship process

2016-08-06 Thread Ben Rosser
On Fri, Aug 5, 2016 at 10:35 AM, Neal Gompa  wrote:

> On Fri, Aug 5, 2016 at 3:32 AM, Miroslav Suchý  wrote:
> > I had the talk [1] about Fedora Sponsorship process at Flock. And we had
> > very interesting follow-up discussion.
> >
> > We come up with several improvements, which should be easy to implement
> and
> > may improve the process a lot. I am posting it here so more people can
> see
> > that and join the discussion.
> >
>
> Overall, I think the biggest problem with our Fedora contributor
> on-boarding process is that it's not so easy to discover people to
> help people get started. One thing I think Mageia (the other
> distribution I'm primarily involved in) does better is the discovery
> bit. As part of the on-boarding process[1], new contributors are
> encouraged to jump into a dedicated IRC channel (#mageia-mentoring)
> where they can meet people to help them through the process. Something
> like this might make it easier for people to find sponsors and find a
> mentor to teach them about how to make packages and be a Fedora packager.
> Perhaps having a mailing list and an IRC channel for this in Fedora
> might help make this process smoother.
>
> [1]: https://wiki.mageia.org/en/Becoming_a_Mageia_Packager
>
>
Yeah, one thing that I remember when I was trying to become a packager is
that the instructions for how to get sponsored on the wiki contained (and
still contain) the phrase "When submitting a new package, usually a sponsor
finds you", which I think is a bit... overly optimistic in many situations.
Also at the time I was intimidated by the prospect of getting involved with
discussions on this list and IRC, which didn't help.

I looked at the Mageia how-to-become-a-packager process briefly a while ago
(my laptop dual-boots Fedora and Mageia, although I am primarily a Fedora
person), and I did notice how it seemed more hands on than ours. A
dedicated place for new contributors to go and meet potential sponsors or
other mentors, be that IRC or a mailing list, would probably be a good idea.

Ben Rosser
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


Re: Improvements of Fedora Sponsorship process

2016-08-06 Thread Ben Rosser
On Sun, Aug 7, 2016 at 12:24 AM, Parag Nemade  wrote:

> Right not for all SIGs but at least for those where its possible. Just
> see there are many such common pattern named packages are waiting in
> queue for their package review. I can think of some patterns like
> perl, python, golang, nodejs, ruby, ghc, mingw, php etc.
>
> Regards,
> Parag.
> --
>

You could maybe also search the summaries of packages for certain keywords
for some other SIGs that don't have common naming schemes? For example, I
just went through the review queue looking for packages with the word
"game" somewhere in the summary to build a list of unreviewed packages for
the Games SIG.

Admittedly, I'm struggling to think of another group of packages this sort
of pattern would be as easily applicable to, and you won't be as accurate
as you would be with getting, say, Python or NodeJS packages, but it might
help if we want to automatically catalog the queue.

Ben Rosser
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


Re: Improvements of Fedora Sponsorship process

2016-08-06 Thread Parag Nemade
Hi,

On Sat, Aug 6, 2016 at 1:49 AM, Mikolaj Izdebski  wrote:
> On 08/05/2016 10:31 AM, Parag Nemade wrote:
>>> b) fedora-review is run automatically by some bot/script just after review
>>> have been submitted.
>>
>>  Can a new utility be written for this as I don't think that long
>> fedora-review output is helpful? Most checks have no markings in them.
>> How can it be helpful to package submitter?
>
> You can configure which fedora-review checks are ran, for example
> exclude any non-automated checks.

I suppose then Generic group checks are sufficient here.

>
>>> c) Create wiki page with list of sponsors willing to accept new sponsoree.
>>> And list area of expertise of sponsors (e.g. java, python, IoT...). This
>>> will make for sponsoree easier to find right sponsor. Because we have some
>>> sponsors, who are active but are not willing to accept new sponsoree right
>>> now.
>>
>> This can be in addition to above, Why not run a script frequently and
>> check bugzilla and based on common naming CC the related SIG group?
>> e.g. if a package review is submitted whose name contains python then
>> add cc python SIG group that will notify actual group people and
>> someone can find interest and review the package. I know this is in
>> general suggestion but I suppose every SIG is also having some
>> Sponsors who can sponsor new contributor packages.
>
> This won't work for all SIGs. For example, Java packages don't have any
> common naming scheme. If you just search for "Java" in review requests,
> almost all results will be false-positives (eg. from "JavaScript") and
> you won't find most of relevant reviews this way.
>
> I think that wiki page could work for this purpose.

Right not for all SIGs but at least for those where its possible. Just
see there are many such common pattern named packages are waiting in
queue for their package review. I can think of some patterns like
perl, python, golang, nodejs, ruby, ghc, mingw, php etc.

Regards,
Parag.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


Re: Improvements of Fedora Sponsorship process

2016-08-06 Thread Michael Scherer
On Fri, Aug 05, 2016 at 09:32:28AM +0200, Miroslav Suchý wrote:
> I had the talk [1] about Fedora Sponsorship process at Flock. And we
> had very interesting follow-up discussion.

So I kinda missed it, since for some reason, i tought this was
about financial sponsorship.
(Given that I forgot words in each title of my own talks, I can't
really complain much)


> c) Create wiki page with list of sponsors willing to accept new
> sponsoree. And list area of expertise of sponsors (e.g. java,
> python, IoT...). This will make for sponsoree easier to find right
> sponsor. Because we have some sponsors, who are active but are not
> willing to accept new sponsoree right now.

I think that's a good idea, but wouldn't it risk getting out
of date after some time ?

Should someone be in charge of it ?
 
> d) When sponsors is not active for 2 years [*] - that means not just
> in sponsoring work, but there is no activity in BZ, koji, wiki and
> any other Fedora service at all (guessed by reading log of fedmsg),
> then his sponsor status is removed. We will assume that the sponsor
> is gone for good.

what happen to the existing sponsored packagers ? (ie, do they get reassigned
to a new sponsor ?)

-- 
Michael Scherer
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


Re: Improvements of Fedora Sponsorship process

2016-08-05 Thread Mikolaj Izdebski
On 08/05/2016 10:31 AM, Parag Nemade wrote:
>> b) fedora-review is run automatically by some bot/script just after review
>> have been submitted.
> 
>  Can a new utility be written for this as I don't think that long
> fedora-review output is helpful? Most checks have no markings in them.
> How can it be helpful to package submitter?

You can configure which fedora-review checks are ran, for example
exclude any non-automated checks.

>> c) Create wiki page with list of sponsors willing to accept new sponsoree.
>> And list area of expertise of sponsors (e.g. java, python, IoT...). This
>> will make for sponsoree easier to find right sponsor. Because we have some
>> sponsors, who are active but are not willing to accept new sponsoree right
>> now.
> 
> This can be in addition to above, Why not run a script frequently and
> check bugzilla and based on common naming CC the related SIG group?
> e.g. if a package review is submitted whose name contains python then
> add cc python SIG group that will notify actual group people and
> someone can find interest and review the package. I know this is in
> general suggestion but I suppose every SIG is also having some
> Sponsors who can sponsor new contributor packages.

This won't work for all SIGs. For example, Java packages don't have any
common naming scheme. If you just search for "Java" in review requests,
almost all results will be false-positives (eg. from "JavaScript") and
you won't find most of relevant reviews this way.

I think that wiki page could work for this purpose.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


Re: Improvements of Fedora Sponsorship process

2016-08-05 Thread Neal Gompa
On Fri, Aug 5, 2016 at 3:32 AM, Miroslav Suchý  wrote:
> I had the talk [1] about Fedora Sponsorship process at Flock. And we had
> very interesting follow-up discussion.
>
> We come up with several improvements, which should be easy to implement and
> may improve the process a lot. I am posting it here so more people can see
> that and join the discussion.
>

Overall, I think the biggest problem with our Fedora contributor
on-boarding process is that it's not so easy to discover people to
help people get started. One thing I think Mageia (the other
distribution I'm primarily involved in) does better is the discovery
bit. As part of the on-boarding process[1], new contributors are
encouraged to jump into a dedicated IRC channel (#mageia-mentoring)
where they can meet people to help them through the process. Something
like this might make it easier for people to find sponsors and find a
mentor to teach them about how to make packages and be a Fedora packager.
Perhaps having a mailing list and an IRC channel for this in Fedora
might help make this process smoother.

[1]: https://wiki.mageia.org/en/Becoming_a_Mageia_Packager


-- 
真実はいつも一つ!/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


Re: Improvements of Fedora Sponsorship process

2016-08-05 Thread Rex Dieter
Miroslav Suchý wrote:

> I had the talk [1] about Fedora Sponsorship process at Flock. And we had
> very interesting follow-up discussion.
> 
> We come up with several improvements, which should be easy to implement
> and may improve the process a lot. I am posting it here so more people
> can see that and join the discussion.
> 
> a) Sponsoree (who apply for package maintainer status) is required to
> create Copr project 

*required*?  No, strongly encouraged maybe.



As an aside, Copr doesn't require CLA+1 ?

(If not, isn't that just asking to be abused/spammed, like the we've seen 
elsewhere?)

-- Rex
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


Re: Improvements of Fedora Sponsorship process

2016-08-05 Thread Parag Nemade
Hi,

On Fri, Aug 5, 2016 at 1:02 PM, Miroslav Suchý  wrote:
> I had the talk [1] about Fedora Sponsorship process at Flock. And we had
> very interesting follow-up discussion.
>
> We come up with several improvements, which should be easy to implement and
> may improve the process a lot. I am posting it here so more people can see
> that and join the discussion.
>
> a) Sponsoree (who apply for package maintainer status) is required to create
> Copr project and maintain the package there until he get the package into
> Fedora. This should show his endurance to sponsors. It will improve the
> morale of the sponsoree as the package is immediately ready for other users.
> And it is not wiped after 14 days as scratch builds in Koji.

Few package submitter are using this currently, it will be good
improvement for new contributors to use Copr.

>
> b) fedora-review is run automatically by some bot/script just after review
> have been submitted.

 Can a new utility be written for this as I don't think that long
fedora-review output is helpful? Most checks have no markings in them.
How can it be helpful to package submitter?

> c) Create wiki page with list of sponsors willing to accept new sponsoree.
> And list area of expertise of sponsors (e.g. java, python, IoT...). This
> will make for sponsoree easier to find right sponsor. Because we have some
> sponsors, who are active but are not willing to accept new sponsoree right
> now.

This can be in addition to above, Why not run a script frequently and
check bugzilla and based on common naming CC the related SIG group?
e.g. if a package review is submitted whose name contains python then
add cc python SIG group that will notify actual group people and
someone can find interest and review the package. I know this is in
general suggestion but I suppose every SIG is also having some
Sponsors who can sponsor new contributor packages.

>
> d) When sponsors is not active for 2 years [*] - that means not just in
> sponsoring work, but there is no activity in BZ, koji, wiki and any other
> Fedora service at all (guessed by reading log of fedmsg), then his sponsor
> status is removed. We will assume that the sponsor is gone for good.

Well good information for other people or FESCo to take action and
orphan their packages as well ;-)

>
> e) When the package review is still not assigned to anybody after 3 months
> [*], then 3 [*] random sponsors are added to CC and asked to proceed with
> the review despite the fact that it likely doesn't belong to their area of
> expertise. This should helps us to get rid of stalled review, which are
> waiting for ages to get some sponsor.

Was there any discussion on what to do with existing stalled package
reviews? I think we should go and close stalled reviews where there is
no update from package review submitter for last six months at least.
Those where reviewer is not progressing, just remove the assignee and
any fedora-review? flag. The review queue I am considering here is
FE-NEEDSPONSOR queue and "tickets under review" queue.

> Those are the ideas which came up at Flock. Please comment this. And if we
> come to some conclusion, I can pass it to FeSCo for approval.
>
> [1] http://miroslav.suchy.cz/presentations/flock2016/sponsors/#/
>
>   Please note that the data in this presentation is based only on data I
> was able to gather and I am aware the it does not reflect 100% the reality.
> But it approximately gives us the order of magnitude of the reality and
> approximately ratio.
>
> [*] I just made up this number. Feel free to discuss appropriate interval.
>

Regards,
Parag.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


Re: Improvements of Fedora Sponsorship process

2016-08-05 Thread Vít Ondruch


Dne 5.8.2016 v 09:32 Miroslav Suchý napsal(a):
> I had the talk [1] about Fedora Sponsorship process at Flock. And we
> had very interesting follow-up discussion.
>
> We come up with several improvements, which should be easy to
> implement and may improve the process a lot. I am posting it here so
> more people can see that and join the discussion.
>
> a) Sponsoree (who apply for package maintainer status) is required to
> create Copr project and maintain the package there until he get the
> package into Fedora. This should show his endurance to sponsors. It
> will improve the morale of the sponsoree as the package is immediately
> ready for other users. And it is not wiped after 14 days as scratch
> builds in Koji.

You have not noted it here and probably not thought about it, but the
advantage of Copr is that it actually provides hosting for SRPMs and it
provides dist-git as well, so one could send a link to .spec file
referring to dist git. That would be actually quite nice benefit, since
newcomers typically struggles with such questions as "where to put my
SRPM/.spec file".


Vít
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org