[gentoo-project] Gentoo Recruiters need your help!

[gentoo-project] Gentoo Recruiters need your help!

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi all,

The recruiters team needs your help once again. The manpower and time
availability in the team is significantly low so we would welcome
developers interested in assisting us and becoming full-time recruiters.
Before you apply, please consider that this role requires a great deal
of time and flexibility. I am sure you remember your reviews, which
may have taken quite a few hours to complete. If you feel like you are
up to the task, and committed to stay around for a while, please get
in touch with us to discuss the first steps of your training process.
In case of multiple applicants, we may prioritize experienced
developers since they may require less time for training.

- -- 
Regards,
Markos Chandras
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQF8BAEBCgBmBQJUZlEUXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx
RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZE3gIALTZcMPdOjH/fMNYztS4rV2b
5y1cY9JazOdt0tPVhicq7cOyezQEf/Aveb7D+E5cAvmIXHg6kLnmqzlLDv0N1Cps
MWlZd264wOhapA8S8DGXFqlOn0ID9hU2ctMWG6gLsA5uo7ckWCU8TwDw/kT3roM/
pE2xfywarunjmvJ4QeqBWvnzj6GIM8Ihe3Iwfi6g4KKbAcQ+Ad+QXWgFavKXgt+/
qHKiGxfFAj0DbvOqfIH5nf/MUeF3clE+hIFJZMiTARUEXo+GKnON4GCx1DEo2EpT
XNzm8xcQddSkNWKggpVz4255V91xA625w8y7nKEgZqODmhuMhMOrEbBI7rWAR2o=
=tByM
-----END PGP SIGNATURE-----

Re: [gentoo-project] Gentoo Recruiters need your help!

[hasufell]

On 11/14/2014 07:59 PM, Markos Chandras wrote:
> Hi all,
> 
> The recruiters team needs your help once again. The manpower and time
> availability in the team is significantly low so we would welcome
> developers interested in assisting us and becoming full-time recruiters.
> Before you apply, please consider that this role requires a great deal
> of time and flexibility. I am sure you remember your reviews, which
> may have taken quite a few hours to complete. If you feel like you are
> up to the task, and committed to stay around for a while, please get
> in touch with us to discuss the first steps of your training process.
> In case of multiple applicants, we may prioritize experienced
> developers since they may require less time for training.
> 

We should recruit less people and instead make an effort to review other
peoples overlays and include a list of high-quality overlays on our website.

The good part is: any dev can do this and it moves away from our broken
centralized packaging model.
In addition, this will take off workload from the recruiters team.

[gentoo-project] Re: Gentoo Recruiters need your help!

[Michael Palimaka]

On 16/11/14 00:43, hasufell wrote:
> On 11/14/2014 07:59 PM, Markos Chandras wrote:
>> Hi all,
>>
>> The recruiters team needs your help once again. The manpower and time
>> availability in the team is significantly low so we would welcome
>> developers interested in assisting us and becoming full-time recruiters.
>> Before you apply, please consider that this role requires a great deal
>> of time and flexibility. I am sure you remember your reviews, which
>> may have taken quite a few hours to complete. If you feel like you are
>> up to the task, and committed to stay around for a while, please get
>> in touch with us to discuss the first steps of your training process.
>> In case of multiple applicants, we may prioritize experienced
>> developers since they may require less time for training.
>>
> 
> We should recruit less people and instead make an effort to review other
> peoples overlays and include a list of high-quality overlays on our website.
> 
> The good part is: any dev can do this and it moves away from our broken
> centralized packaging model.
> In addition, this will take off workload from the recruiters team.

High-quality, reviewed overlays is a good idea. We still need more
recruiters though.

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[Rich Freeman]

On Sat, Nov 15, 2014 at 8:57 AM, Michael Palimaka <kensington@gentoo.org> wrote:
> On 16/11/14 00:43, hasufell wrote:
>>
>> We should recruit less people and instead make an effort to review other
>> peoples overlays and include a list of high-quality overlays on our website.
>>
>> The good part is: any dev can do this and it moves away from our broken
>> centralized packaging model.
>> In addition, this will take off workload from the recruiters team.
>
> High-quality, reviewed overlays is a good idea. We still need more
> recruiters though.
>

++

I'm all for implementing a more distributed model, though I think it
would take a bit more than just a list of overlays (we need better
policies around eclass changes and the like, unless we want overlays
to fork them).  That said, we've talked about that many times and
until we're happily buzzing along with 47 high-quality overlays let's
not turn off the developer production factory.

-- 
Rich

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[hasufell]

On 11/15/2014 03:44 PM, Rich Freeman wrote:
> On Sat, Nov 15, 2014 at 8:57 AM, Michael Palimaka <kensington@gentoo.org> wrote:
>> On 16/11/14 00:43, hasufell wrote:
>>>
>>> We should recruit less people and instead make an effort to review other
>>> peoples overlays and include a list of high-quality overlays on our website.
>>>
>>> The good part is: any dev can do this and it moves away from our broken
>>> centralized packaging model.
>>> In addition, this will take off workload from the recruiters team.
>>
>> High-quality, reviewed overlays is a good idea. We still need more
>> recruiters though.
>>
> 
> ++
> 
> I'm all for implementing a more distributed model, though I think it
> would take a bit more than just a list of overlays (we need better
> policies around eclass changes and the like, unless we want overlays
> to fork them).  That said, we've talked about that many times and
> until we're happily buzzing along with 47 high-quality overlays let's
> not turn off the developer production factory.
> 

Turning it off will decrease organizational problems, make the
distribution more focused and eventually more high quality, because
people would be able to actually work together on the _core_ of gentoo
(toolchain, base-system, eclasses, PM...).

So, I was specifically talking about a distributed model _opposed_ to
adding new "developers" every time we are short on a team.

Of course, this would also require us to actually work together _with_
the community.

[gentoo-project] Re: Gentoo Recruiters need your help!

[Michael Palimaka]

On 16/11/14 02:00, hasufell wrote:
> On 11/15/2014 03:44 PM, Rich Freeman wrote:
>> On Sat, Nov 15, 2014 at 8:57 AM, Michael Palimaka <kensington@gentoo.org> wrote:
>>> On 16/11/14 00:43, hasufell wrote:
>>>>
>>>> We should recruit less people and instead make an effort to review other
>>>> peoples overlays and include a list of high-quality overlays on our website.
>>>>
>>>> The good part is: any dev can do this and it moves away from our broken
>>>> centralized packaging model.
>>>> In addition, this will take off workload from the recruiters team.
>>>
>>> High-quality, reviewed overlays is a good idea. We still need more
>>> recruiters though.
>>>
>>
>> ++
>>
>> I'm all for implementing a more distributed model, though I think it
>> would take a bit more than just a list of overlays (we need better
>> policies around eclass changes and the like, unless we want overlays
>> to fork them).  That said, we've talked about that many times and
>> until we're happily buzzing along with 47 high-quality overlays let's
>> not turn off the developer production factory.
>>
> 
> Turning it off will decrease organizational problems, make the
> distribution more focused and eventually more high quality, because
> people would be able to actually work together on the _core_ of gentoo
> (toolchain, base-system, eclasses, PM...).
> 
> So, I was specifically talking about a distributed model _opposed_ to
> adding new "developers" every time we are short on a team.
> 
> Of course, this would also require us to actually work together _with_
> the community.

When can we expect your announcement of a new project working towards a
more distributed model?

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[Jauhien Piatlicki]

[-- Attachment #1: Type: text/plain, Size: 2217 bytes --]

15.11.14 16:00, hasufell написав(ла):
> On 11/15/2014 03:44 PM, Rich Freeman wrote:
>> On Sat, Nov 15, 2014 at 8:57 AM, Michael Palimaka <kensington@gentoo.org> wrote:
>>> On 16/11/14 00:43, hasufell wrote:
>>>>
>>>> We should recruit less people and instead make an effort to review other
>>>> peoples overlays and include a list of high-quality overlays on our website.
>>>>
>>>> The good part is: any dev can do this and it moves away from our broken
>>>> centralized packaging model.
>>>> In addition, this will take off workload from the recruiters team.
>>>
>>> High-quality, reviewed overlays is a good idea. We still need more
>>> recruiters though.
>>>
>>
>> ++
>>
>> I'm all for implementing a more distributed model, though I think it
>> would take a bit more than just a list of overlays (we need better
>> policies around eclass changes and the like, unless we want overlays
>> to fork them).  That said, we've talked about that many times and
>> until we're happily buzzing along with 47 high-quality overlays let's
>> not turn off the developer production factory.
>>
> 
> Turning it off will decrease organizational problems, make the
> distribution more focused and eventually more high quality, because
> people would be able to actually work together on the _core_ of gentoo
> (toolchain, base-system, eclasses, PM...).
> 
> So, I was specifically talking about a distributed model _opposed_ to
> adding new "developers" every time we are short on a team.
> 
> Of course, this would also require us to actually work together _with_
> the community.
> 

+1

It would be probably good to have in the tree only the core components and move other stuff to the thematic overlays.

Then we can have a clear understanding, how things should be: if something is a part of the core system, it goes to the tree, if something is a scientific packages, it lives in the science overlay, if something is a java stuff it lives in the java overlay, etc.

It will make easier for users both looking for packages and contributing to the project.

Though we need to create clear policies for overlays and review them based on those policies.

--
Jauhien



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[heroxbd]

[-- Attachment #1: Type: text/plain, Size: 692 bytes --]

Jauhien Piatlicki <jauhien@gentoo.org> writes:

> It would be probably good to have in the tree only the core components and move other stuff to the thematic overlays.
>
> Then we can have a clear understanding, how things should be: if
> something is a part of the core system, it goes to the tree, if
> something is a scientific packages, it lives in the science overlay,
> if something is a java stuff it lives in the java overlay, etc.

This is a good idea.  One difficulty: how to handle inter-overlay
dependence?  Either the dependency should be expressed by overlay +
ebuild, or the dependent ebuild should be moved into the "core overlay".
I haven't figured out a clean solution yet.

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[hasufell]

On 11/18/2014 04:19 AM, heroxbd@gentoo.org wrote:
> Jauhien Piatlicki <jauhien@gentoo.org> writes:
> 
>> It would be probably good to have in the tree only the core components and move other stuff to the thematic overlays.
>>
>> Then we can have a clear understanding, how things should be: if
>> something is a part of the core system, it goes to the tree, if
>> something is a scientific packages, it lives in the science overlay,
>> if something is a java stuff it lives in the java overlay, etc.
> 
> This is a good idea.  One difficulty: how to handle inter-overlay
> dependence?  Either the dependency should be expressed by overlay +
> ebuild, or the dependent ebuild should be moved into the "core overlay".
> I haven't figured out a clean solution yet.
> 

git submodules?

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 408 bytes --]

On Tue, 18 Nov 2014 18:23:41 +0100
hasufell <hasufell@gentoo.org> wrote:
> > This is a good idea.  One difficulty: how to handle inter-overlay
> > dependence?  Either the dependency should be expressed by overlay +
> > ebuild, or the dependent ebuild should be moved into the "core
> > overlay". I haven't figured out a clean solution yet.
> 
> git submodules?

Uh... What.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[Jauhien Piatlicki]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

On 11/18/2014 06:23 PM, hasufell wrote:
> On 11/18/2014 04:19 AM, heroxbd@gentoo.org wrote:
>> Jauhien Piatlicki <jauhien@gentoo.org> writes:
>>
>>> It would be probably good to have in the tree only the core components and move other stuff to the thematic overlays.
>>>
>>> Then we can have a clear understanding, how things should be: if
>>> something is a part of the core system, it goes to the tree, if
>>> something is a scientific packages, it lives in the science overlay,
>>> if something is a java stuff it lives in the java overlay, etc.
>>
>> This is a good idea.  One difficulty: how to handle inter-overlay
>> dependence?  Either the dependency should be expressed by overlay +
>> ebuild, or the dependent ebuild should be moved into the "core overlay".
>> I haven't figured out a clean solution yet.
>>
> 
> git submodules?
> 

mmm, are you serious? )


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[hasufell]

On 11/18/2014 07:33 PM, Jauhien Piatlicki wrote:
> On 11/18/2014 06:23 PM, hasufell wrote:
>> On 11/18/2014 04:19 AM, heroxbd@gentoo.org wrote:
>>> Jauhien Piatlicki <jauhien@gentoo.org> writes:
>>>
>>>> It would be probably good to have in the tree only the core components and move other stuff to the thematic overlays.
>>>>
>>>> Then we can have a clear understanding, how things should be: if
>>>> something is a part of the core system, it goes to the tree, if
>>>> something is a scientific packages, it lives in the science overlay,
>>>> if something is a java stuff it lives in the java overlay, etc.
>>>
>>> This is a good idea.  One difficulty: how to handle inter-overlay
>>> dependence?  Either the dependency should be expressed by overlay +
>>> ebuild, or the dependent ebuild should be moved into the "core overlay".
>>> I haven't figured out a clean solution yet.
>>>
>>
>> git submodules?
>>
> 
> mmm, are you serious? )
> 

I really have no idea. It made sense for a moment. And then that moment
was gone.

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[Rich Freeman]

On Sat, Nov 15, 2014 at 10:00 AM, hasufell <hasufell@gentoo.org> wrote:
>
> Turning it off will decrease organizational problems, make the
> distribution more focused and eventually more high quality, because
> people would be able to actually work together on the _core_ of gentoo
> (toolchain, base-system, eclasses, PM...).
>

Having fewer people maintaining packages will not make more people
work on toolchain, base-system, eclasses, portage, etc.

If somebody is actively contributing to something in critical need
such as one of those I'd certainly encourage the recruiters to
prioritize their application.  However, turning away help elsewhere
won't help us out.

I'd suggest moving forward with building the new before getting rid of the old.

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 11/15/2014 08:29 PM, Rich Freeman wrote:
> On Sat, Nov 15, 2014 at 10:00 AM, hasufell <hasufell@gentoo.org>
> wrote:
>> 
>> Turning it off will decrease organizational problems, make the 
>> distribution more focused and eventually more high quality,
>> because people would be able to actually work together on the
>> _core_ of gentoo (toolchain, base-system, eclasses, PM...).
>> 
> 
> Having fewer people maintaining packages will not make more people 
> work on toolchain, base-system, eclasses, portage, etc.
> 
> If somebody is actively contributing to something in critical need 
> such as one of those I'd certainly encourage the recruiters to 
> prioritize their application.  However, turning away help
> elsewhere won't help us out.
> 
> I'd suggest moving forward with building the new before getting rid
> of the old.
> 
Can we please stay on topic? This thread is about getting some help
with recruiters. If you need to discuss something else can you please
fork this thread properly?

- -- 
Regards,
Markos Chandras
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQF8BAEBCgBmBQJUaNV7XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx
RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8Zq9cH/R/P+DFnIAhvTvN2MJvbXvN1
1RFGd9BNvEGjW6QN5StbItKgZuuF823MXd2mK09OEXG2nlv8ms2I7yWFwXlum7Up
n5xyPGd6Do4ZnQv3vKGzMvoRUwe+a182NZvULasd8ITlux8Qj2cDuUgPMdlNtxj8
gPJ6xGnZrWDkAKJd93koHRVuxmJUwSyGPXBpwapo/GRr14TrWvqc0jABPC5S/aun
7L2/tvSJFKokSBk94bjBft+AGOp1rSDxaUH5s5bxFzK0NljHcTnuNeQ2J6MecY2z
+NcrLHIO8wcgapHNasg4fADW+UohJInheNM7k0lsxvovAIwyKZhqoLvN1Ui4Bvk=
=HxaU
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[Mikle Kolyada]

16.11.2014 19:48, Markos Chandras пишет:
> On 11/15/2014 08:29 PM, Rich Freeman wrote:
> > On Sat, Nov 15, 2014 at 10:00 AM, hasufell <hasufell@gentoo.org>
> > wrote:
> >>
> >> Turning it off will decrease organizational problems, make the
> >> distribution more focused and eventually more high quality,
> >> because people would be able to actually work together on the
> >> _core_ of gentoo (toolchain, base-system, eclasses, PM...).
> >>
>
> > Having fewer people maintaining packages will not make more people
> > work on toolchain, base-system, eclasses, portage, etc.
>
> > If somebody is actively contributing to something in critical need
> > such as one of those I'd certainly encourage the recruiters to
> > prioritize their application.  However, turning away help
> > elsewhere won't help us out.
>
> > I'd suggest moving forward with building the new before getting rid
> > of the old.
>
> Can we please stay on topic? This thread is about getting some help
> with recruiters. If you need to discuss something else can you please
> fork this thread properly?
>
So, back to the topic. Which skills are needed to be a recruiter?

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 11/16/2014 04:55 PM, Mikle Kolyada wrote:
> 
> 16.11.2014 19:48, Markos Chandras пишет:
>> On 11/15/2014 08:29 PM, Rich Freeman wrote:
>>> On Sat, Nov 15, 2014 at 10:00 AM, hasufell
>>> <hasufell@gentoo.org> wrote:
>>>> 
>>>> Turning it off will decrease organizational problems, make
>>>> the distribution more focused and eventually more high
>>>> quality, because people would be able to actually work
>>>> together on the _core_ of gentoo (toolchain, base-system,
>>>> eclasses, PM...).
>>>> 
>> 
>>> Having fewer people maintaining packages will not make more
>>> people work on toolchain, base-system, eclasses, portage, etc.
>> 
>>> If somebody is actively contributing to something in critical
>>> need such as one of those I'd certainly encourage the
>>> recruiters to prioritize their application.  However, turning
>>> away help elsewhere won't help us out.
>> 
>>> I'd suggest moving forward with building the new before getting
>>> rid of the old.
>> 
>> Can we please stay on topic? This thread is about getting some
>> help with recruiters. If you need to discuss something else can
>> you please fork this thread properly?
>> 
> So, back to the topic. Which skills are needed to be a recruiter?
> 

First of all *time*. Time and long term commitment is crucial here.
Then you need some basic technical skills which you normally get after
being a developer for a good 8-12 months or so. So, staffers and new
developers can't really be recruiters. Apart from that, some kind of
basic social skills are required, in the sense that you need to be
understanding, helpful and patient with recruits, especially when the
mentors have failed to prepare them properly ;) Think about your
recruiter and if he did a good job with you. If yes, then great. Be
like him :) if not, then great again. Think of what you would like him
to have done better? Would you have done it better yourself? If yes,
then great, you would most likely be a good addition to the team.

- -- 
Regards,
Markos Chandras
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQF8BAEBCgBmBQJUaNkmXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx
RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZFvwH/1v6wIskBjsLjP3fVkQr3vGV
j/Ea3jsO3vhO5PiXVwLiD71uOOPjSBVdleT2y2e/bLkfvPnB45nCbQVMmYgIZCIV
OHi7xtWt2+pUWq4Nl/t1Vib+oB+ERHjq0JyExQNjxg7HqG6NYs6oHpN0NeMeq1t5
dHm6Ls1rU2+pcJmuQd2i6p0MtVW06iI94gVhlG+CWYoke5IQ9Tvgr8I5egcwRQ3k
ELFZdzTrdWaR10MNQoNCebm85/QV8C+zDmSCaet11NLjge2V2GOKTuBVgtgHMapD
ki3AvSOnJ8DzjQEwipIQ81bbAkzc15VBxtEIMhl7n4D1RCZvXRNzUH+jiFH99YY=
=RAeG
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[Mikle Kolyada]

[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]


16.11.2014 20:04, Markos Chandras пишет:
> First of all *time*. Time and long term commitment is crucial here.
> Then you need some basic technical skills which you normally get after
> being a developer for a good 8-12 months or so. So, staffers and new
> developers can't really be recruiters. Apart from that, some kind of
> basic social skills are required, in the sense that you need to be
> understanding, helpful and patient with recruits, especially when the
> mentors have failed to prepare them properly ;) Think about your
> recruiter and if he did a good job with you. If yes, then great. Be
> like him :) if not, then great again. Think of what you would like him
> to have done better? Would you have done it better yourself? If yes,
> then great, you would most likely be a good addition to the team.
Well, i sent a message to recruiters about help few months ago, but
nobody answered to me yet. If you need help, i think i can do it. After
all, i noticed, not all new developers understand what they must to do (
i have an example, but it's another discussion)

[-- Attachment #2: Type: text/html, Size: 1624 bytes --]

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 11/16/2014 05:19 PM, Mikle Kolyada wrote:
> 
> 16.11.2014 20:04, Markos Chandras пишет:
>> First of all *time*. Time and long term commitment is crucial
>> here. Then you need some basic technical skills which you
>> normally get after being a developer for a good 8-12 months or
>> so. So, staffers and new developers can't really be recruiters.
>> Apart from that, some kind of basic social skills are required,
>> in the sense that you need to be understanding, helpful and
>> patient with recruits, especially when the mentors have failed to
>> prepare them properly ;) Think about your recruiter and if he did
>> a good job with you. If yes, then great. Be like him :) if not,
>> then great again. Think of what you would like him to have done
>> better? Would you have done it better yourself? If yes, then
>> great, you would most likely be a good addition to the team.
> Well, i sent a message to recruiters about help few months ago,
> but nobody answered to me yet. If you need help, i think i can do
> it. After all, i noticed, not all new developers understand what
> they must to do ( i have an example, but it's another discussion)
> 

I remember that email but we had no plans for expanding our team back
then. We do now :)

- -- 
Regards,
Markos Chandras
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQF8BAEBCgBmBQJUaOeLXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx
RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZFwYH/3NZVPsgTwk3hhyNeKL5C4O4
Kajqs1hRmmlABDmf5WEk05uEqeBD1/Iui9N0bihhqexAKVWFDhshJUFV3QMEda2f
jeqGXFhhY3D6ndZjM8AwqTvFSW8TWT5RdjXPBI44nh2mgUOGQQ+CGAAJH8/8w07e
6cnv7yoYCn01SmZ0m/Yzb+CBNBi3YXFEpnf6albBP3PqDIhE7XsxpDueqzKgYMQo
gTKGyceyzAzoLKzz9MqRyQlx1BiYV6Ksz1TaEXQ49NkW8w8OKOdIDttRun/EBDP5
mn3AtcflKrFHJkLvS3M0m0Uv3Y4y6QGuYZAm13wdLKEtDXcpaK+sahpO1SrG/k0=
=nfKa
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[Mikle Kolyada]

16.11.2014 21:06, Markos Chandras пишет:
> On 11/16/2014 05:19 PM, Mikle Kolyada wrote:
>
> > 16.11.2014 20:04, Markos Chandras пишет:
> >> First of all *time*. Time and long term commitment is crucial
> >> here. Then you need some basic technical skills which you
> >> normally get after being a developer for a good 8-12 months or
> >> so. So, staffers and new developers can't really be recruiters.
> >> Apart from that, some kind of basic social skills are required,
> >> in the sense that you need to be understanding, helpful and
> >> patient with recruits, especially when the mentors have failed to
> >> prepare them properly ;) Think about your recruiter and if he did
> >> a good job with you. If yes, then great. Be like him :) if not,
> >> then great again. Think of what you would like him to have done
> >> better? Would you have done it better yourself? If yes, then
> >> great, you would most likely be a good addition to the team.
> > Well, i sent a message to recruiters about help few months ago,
> > but nobody answered to me yet. If you need help, i think i can do
> > it. After all, i noticed, not all new developers understand what
> > they must to do ( i have an example, but it's another discussion)
>
>
> I remember that email but we had no plans for expanding our team back
> then. We do now :)
>

So, my letter is still actual, i think i can help.

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[Justin (jlec)]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

On 16/11/14 18:19, Mikle Kolyada wrote:
After all, i noticed,
> not all new developers understand what they must to do ( i have an example, but
> it's another discussion)

It is crucial that report such things to us so that we can guide the mentors
more closely. Thanks.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[Manuel Rüger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 17.11.2014 10:39, Justin (jlec) wrote:
> On 16/11/14 18:19, Mikle Kolyada wrote: After all, i noticed,
>> not all new developers understand what they must to do ( i have
>> an example, but it's another discussion)
> 
> It is crucial that report such things to us so that we can guide
> the mentors more closely. Thanks.
> 

I know the recruiters teams is short on time, but feedback to mentors
is really appreciated (at least I do).
Maybe you could push a short mail to the mentors after you set up the
new dev?
This could include the recruiter-reviewed quizzes (so the mentor can
diff with the one she or he reviewed. Better prereviews means less
work for the recruiters) and a note that the mentor has to check the
commits of the new dev in the first month (this should be already
known by the mentor, but a subtle hint doesn't harm. Maybe add some
best practices for that).


Cheers

Manuel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJUacr2XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcGJIP/ju5vUaXhZVZrJUVxG/zaQro
Gi0w+8XEnPKGIrFcviJq0wqKV96yuXe2PRL5In143FOhX82msmxAT+Afi/s3VEhi
QkjG1bKKrvpzC41gxJ1gRYC0202m+StzBYYjpz4MhP1hYnfGHRmc3F00QYxFFijQ
PSByb3q79OvWhOIV+U3Cylawu+U/7acnJTN7hEwt1oWaj4qd22p4RyzgdOOcRx4U
+lSq5FMLcrX9c9/9e5bHbrvAF4C2CJcQVDGIfxd/6UvSTODizA4oSaZ7l96WCE9E
Cra+Dn+Yl6X6EZF/XXJ/YeGLMcWQaLrB/7z30ryHiu2gOCZ18sBon6FycC2emzF/
kifik7cAD3vWXPT1RyVFOayAtUzUojqgBauNESao31cCk8dSdEoqgq6PppiIaAtg
ihxGA7iTQ5b6qwON7dhDHgdbQr0dfw7pR5RowpBDFC/6RT2bYVC0EHAxnTwsE8qV
kqde5mhIBItumRqWa055l5ThoaUlVSqFGi4YofDvsGGMJzv19xs9SsLCFobpYBmb
gYIYQptw0nSBM/jG2DWPbw6NLs6co44z/wH+6+D6GwdFWScBv0r9hu+Bpnchahc7
kDR+y24ynsk6EX5L4u+844vXyiel98zRU4hp5HCaO9RX9boG6PFqfh0FYwS1wdYe
0MTjiqo1dPkLRIvCNpNQ
=F1It
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[Pacho Ramos]

El lun, 17-11-2014 a las 11:16 +0100, Manuel Rüger escribió:
> On 17.11.2014 10:39, Justin (jlec) wrote:
> > On 16/11/14 18:19, Mikle Kolyada wrote: After all, i noticed,
> >> not all new developers understand what they must to do ( i have
> >> an example, but it's another discussion)
> > 
> > It is crucial that report such things to us so that we can guide
> > the mentors more closely. Thanks.
> > 
> 
> I know the recruiters teams is short on time, but feedback to mentors
> is really appreciated (at least I do).
> Maybe you could push a short mail to the mentors after you set up the
> new dev?
> This could include the recruiter-reviewed quizzes (so the mentor can
> diff with the one she or he reviewed. Better prereviews means less
> work for the recruiters) and a note that the mentor has to check the
> commits of the new dev in the first month (this should be already
> known by the mentor, but a subtle hint doesn't harm. Maybe add some
> best practices for that).
> 
> 
> Cheers
> 
> Manuel

Have you think on having a mailing list with recruiters and mentors to
allow all us to ask for doubts, be aware of people willing to be
recruited or become mentors or similar, help us on different tasks is we
are able :) ?

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[Manuel Rüger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 17.11.2014 11:26, Pacho Ramos wrote:
> El lun, 17-11-2014 a las 11:16 +0100, Manuel Rüger escribió:
>> On 17.11.2014 10:39, Justin (jlec) wrote:
>>> On 16/11/14 18:19, Mikle Kolyada wrote: After all, i noticed,
>>>> not all new developers understand what they must to do ( i
>>>> have an example, but it's another discussion)
>>> 
>>> It is crucial that report such things to us so that we can
>>> guide the mentors more closely. Thanks.
>>> 
>> 
>> I know the recruiters teams is short on time, but feedback to
>> mentors is really appreciated (at least I do). Maybe you could
>> push a short mail to the mentors after you set up the new dev? 
>> This could include the recruiter-reviewed quizzes (so the mentor
>> can diff with the one she or he reviewed. Better prereviews means
>> less work for the recruiters) and a note that the mentor has to
>> check the commits of the new dev in the first month (this should
>> be already known by the mentor, but a subtle hint doesn't harm.
>> Maybe add some best practices for that).
>> 
>> 
>> Cheers
>> 
>> Manuel
> 
> Have you think on having a mailing list with recruiters and mentors
> to allow all us to ask for doubts, be aware of people willing to
> be recruited or become mentors or similar, help us on different
> tasks is we are able :) ?
> 
> 

Well I've thought about a subproject (read: mailing list + wiki page)
that does the following:

- - Keep a list of available mentors and the areas of gentoo they want
to mentor new people in the wiki (contributors can see this as a
contact list)
- - Establish contact between interested contributors and mentors (if
they don't know how to approach the mentors)
- - Look out for contributors. Try to persuade them to become devs.
- - Provide support for mentors (quizzes, mentoring in general, lack of
time, etc.)

But I currently don't have the time to run this on my own. If anyone
is interested in this idea, just mail me and we'll see. :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJUaeJLXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNc0MUP/jmpIC2sPHLWZqcr1QhgRdaP
l0cIiMmzOsb/Y8CQ9RYfX2O+Non4SZCULw51mTjmA+opQwD/Vi1j8/IiZh8qtJq9
CYggojZAZt58JX+yG37/Zdi1piT5ppVz+gOeWcB/+TBTbUbApmi7JBlErZUHbtK2
clsuJSuRPgNsOOV3KUaNBK2U2sDTkvR7Ool0RvakuTv0DabhN7zwDxd0Oem8Fsgp
MFKaLRxFdvHTzOMB4DTzlRCqbZfao2kYBPVPPkYZfa3cxgApBA6MA4MuGnRjx398
U+/Fes2DKuWvsr/caqGI6Ps2wogRwdZmhct+T59Cv5+G+3ltZToowHAjGH0lGiUB
C1wOpQVl3lBnwLCRqkQuma6F4ybL8fF1Ol8sPvkLhuQjvEX1lxu3uS+ROUcp8hKa
f73VcOHINFLtPueT92yY75+rolXdN1Uy6xTav6RlIjveEJlJOB+53txnCcAP08uK
ONr+sRiJZPD2wxzsW9FE7/IuiJpCIkn1ojZYnCZXKpzYv7plAiQ/UkiBZ237kpCG
nUe72p7xCxSn/1ZnIT8jinz22V31Q0/QiqOMQ2DPThxFodffgsYjp3FgE8+p+PFC
TEYHFrZVmlmfeoRfKtkNy5p1mAudcXZe/LJWoNhzlqfAQoLMltCoTGCQbwdFhgbF
bUawKSFJ6smR5dNp6yVZ
=GKrj
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[Justin (jlec)]

[-- Attachment #1: Type: text/plain, Size: 1271 bytes --]

On 17/11/14 11:16, Manuel Rüger wrote:
> On 17.11.2014 10:39, Justin (jlec) wrote:
>> On 16/11/14 18:19, Mikle Kolyada wrote: After all, i noticed,
>>> not all new developers understand what they must to do ( i have
>>> an example, but it's another discussion)
> 
>> It is crucial that report such things to us so that we can guide
>> the mentors more closely. Thanks.
> 
> 
> I know the recruiters teams is short on time, but feedback to mentors
> is really appreciated (at least I do).
> Maybe you could push a short mail to the mentors after you set up the
> new dev?
> This could include the recruiter-reviewed quizzes (so the mentor can
> diff with the one she or he reviewed. Better prereviews means less
> work for the recruiters) and a note that the mentor has to check the
> commits of the new dev in the first month (this should be already
> known by the mentor, but a subtle hint doesn't harm. Maybe add some
> best practices for that).
> 

Hi Manuel,

when the recruitment is done, you should get notified through the bug tracker
and by your mentee that the real business starts. There is not additional mail
required.
Your mentee also can provide you all the information like fixed quizzes, review
session logs etc.

Justin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[Manuel Rüger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 17.11.2014 11:27, Justin (jlec) wrote:
> On 17/11/14 11:16, Manuel Rüger wrote:
>> On 17.11.2014 10:39, Justin (jlec) wrote:
>>> On 16/11/14 18:19, Mikle Kolyada wrote: After all, i noticed,
>>>> not all new developers understand what they must to do ( i
>>>> have an example, but it's another discussion)
>> 
>>> It is crucial that report such things to us so that we can
>>> guide the mentors more closely. Thanks.
>> 
>> 
>> I know the recruiters teams is short on time, but feedback to
>> mentors is really appreciated (at least I do). Maybe you could
>> push a short mail to the mentors after you set up the new dev? 
>> This could include the recruiter-reviewed quizzes (so the mentor
>> can diff with the one she or he reviewed. Better prereviews means
>> less work for the recruiters) and a note that the mentor has to
>> check the commits of the new dev in the first month (this should
>> be already known by the mentor, but a subtle hint doesn't harm.
>> Maybe add some best practices for that).
>> 
> 
> Hi Manuel,
> 
> when the recruitment is done, you should get notified through the
> bug tracker and by your mentee that the real business starts. There
> is not additional mail required. Your mentee also can provide you
> all the information like fixed quizzes, review session logs etc.
> 
> Justin
> 

Hi Justin,

I'm aware of that, but I doubt many mentors will ask their mentees for
this information, so this becomes a push-vs-pull problem.

Looking into the webapp, I get the feeling that mentors have different
levels of expectations what's an acceptable answer. Some accept really
brief answers, others "torture" their mentees in detail.

I'm sure you as a recruiter know better if my assumption is valid.
So at least mentors that accept brief answers could profit from
reading recruiter-reviewed quizzes. An alternative to this would be
expanding the webapp to show minimal requirements for each answer to
the mentor.


Maybe
Manuel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJUad9kXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNc4GsP/1nfaKvihFKgkEi7YmrU22Bk
PqIdsy44e/CMRQ1u+A55InrvJ1h8MnRF8uHVCd29s/25r1n1ABqdk8S9gGuqHpnU
vBiwb0ZSjgqLUPP01l5uolMsZxCeFS6g9hPM7FpEe4yIBlYca2uY604e5ib3bWCM
imxCUWY3vTpQ2GelphRW3ityCYpFAE9a0kqhT2gsGdm5tNUbcp6zkRURHIbUMC46
TjaNR39ALLutnWaDE0KusfRh9pKES74o9BoApV16XyrT/w2fvXw4jXIqAItdPIfD
ucazpidfy+HwdsQ+T5+vPFRslawpWy+GXnbw0StCA/HCLOs6JEi25umxAd8aryam
5bsnLTsKTEXuNYS/ciUytjF3xAkUshHsYroNKENBevol891hvSTmqMRS9hvcXNN3
0IqLeMEAQDmlEdwc7RhijnjAZSxZJWl1VCBzNa/zc4p5knIk43PxGNbz4WRQB1kv
gfOOrrYVeN40lF1H/Q7lsIlwj787pNqQtXrr5NiMvw0VP74E1eXsMKJoK6whslbD
uQFaJjHEzF7eIwPCx+1AEVMQy7irJu5bolR9rjz8N/ohBsJJHf9zK0MNiI7Kndgu
UTQQf4juq8VQsx7Ow57t3pkra6AfYJJNXGaZ4sF2Ch5FL1abH0GqXbNWUeYLrQtS
bBWXvBEYSAKZzmE8OR13
=HWYC
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[Justin (jlec)]

[-- Attachment #1: Type: text/plain, Size: 2782 bytes --]

On 17/11/14 12:43, Manuel Rüger wrote:
> On 17.11.2014 11:27, Justin (jlec) wrote:
>> On 17/11/14 11:16, Manuel Rüger wrote:
>>> On 17.11.2014 10:39, Justin (jlec) wrote:
>>>> On 16/11/14 18:19, Mikle Kolyada wrote: After all, i noticed,
>>>>> not all new developers understand what they must to do ( i
>>>>> have an example, but it's another discussion)
>>>
>>>> It is crucial that report such things to us so that we can
>>>> guide the mentors more closely. Thanks.
>>>
>>>
>>> I know the recruiters teams is short on time, but feedback to
>>> mentors is really appreciated (at least I do). Maybe you could
>>> push a short mail to the mentors after you set up the new dev? 
>>> This could include the recruiter-reviewed quizzes (so the mentor
>>> can diff with the one she or he reviewed. Better prereviews means
>>> less work for the recruiters) and a note that the mentor has to
>>> check the commits of the new dev in the first month (this should
>>> be already known by the mentor, but a subtle hint doesn't harm.
>>> Maybe add some best practices for that).
>>>
> 
>> Hi Manuel,
> 
>> when the recruitment is done, you should get notified through the
>> bug tracker and by your mentee that the real business starts. There
>> is not additional mail required. Your mentee also can provide you
>> all the information like fixed quizzes, review session logs etc.
> 
>> Justin
> 
> 
> Hi Justin,
> 
> I'm aware of that, but I doubt many mentors will ask their mentees for
> this information, so this becomes a push-vs-pull problem.
> 
> Looking into the webapp, I get the feeling that mentors have different
> levels of expectations what's an acceptable answer. Some accept really
> brief answers, others "torture" their mentees in detail.
> 
> I'm sure you as a recruiter know better if my assumption is valid.
> So at least mentors that accept brief answers could profit from
> reading recruiter-reviewed quizzes. An alternative to this would be
> expanding the webapp to show minimal requirements for each answer to
> the mentor.

Hi Manuel,

the difference in torture level results in more or less well prepared mentees.
If a mentor is really taking time to go through everything, the recruitment
session with the recruiter are going very fast. Otherwise we need to explain and
teach.

I don't think a mentor will start on its own to critically review it's own
performance. We would rather need a training/supervision of mentors including
detailed feedback at the end.

The recruiter a quite understaffed, so I would suggest to organize as a
senior/junior mentor thing. We have really great senior mentors like swift, who
provide always well prepared mentees. Would is possible to do it that way?


Justin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 11/17/2014 12:23 PM, Justin (jlec) wrote:
> On 17/11/14 12:43, Manuel Rüger wrote:
>> On 17.11.2014 11:27, Justin (jlec) wrote:
>>> On 17/11/14 11:16, Manuel Rüger wrote:
>>>> On 17.11.2014 10:39, Justin (jlec) wrote:
>>>>> On 16/11/14 18:19, Mikle Kolyada wrote: After all, i
>>>>> noticed,
>>>>>> not all new developers understand what they must to do (
>>>>>> i have an example, but it's another discussion)
>>>> 
>>>>> It is crucial that report such things to us so that we can 
>>>>> guide the mentors more closely. Thanks.
>>>> 
>>>> 
>>>> I know the recruiters teams is short on time, but feedback
>>>> to mentors is really appreciated (at least I do). Maybe you
>>>> could push a short mail to the mentors after you set up the
>>>> new dev? This could include the recruiter-reviewed quizzes
>>>> (so the mentor can diff with the one she or he reviewed.
>>>> Better prereviews means less work for the recruiters) and a
>>>> note that the mentor has to check the commits of the new dev
>>>> in the first month (this should be already known by the
>>>> mentor, but a subtle hint doesn't harm. Maybe add some best
>>>> practices for that).
>>>> 
>> 
>>> Hi Manuel,
>> 
>>> when the recruitment is done, you should get notified through
>>> the bug tracker and by your mentee that the real business
>>> starts. There is not additional mail required. Your mentee also
>>> can provide you all the information like fixed quizzes, review
>>> session logs etc.
>> 
>>> Justin
>> 
>> 
>> Hi Justin,
>> 
>> I'm aware of that, but I doubt many mentors will ask their
>> mentees for this information, so this becomes a push-vs-pull
>> problem.
>> 
>> Looking into the webapp, I get the feeling that mentors have
>> different levels of expectations what's an acceptable answer.
>> Some accept really brief answers, others "torture" their mentees
>> in detail.
>> 
>> I'm sure you as a recruiter know better if my assumption is
>> valid. So at least mentors that accept brief answers could profit
>> from reading recruiter-reviewed quizzes. An alternative to this
>> would be expanding the webapp to show minimal requirements for
>> each answer to the mentor.
> 
> Hi Manuel,
> 
> the difference in torture level results in more or less well
> prepared mentees. If a mentor is really taking time to go through
> everything, the recruitment session with the recruiter are going
> very fast. Otherwise we need to explain and teach.
> 
> I don't think a mentor will start on its own to critically review
> it's own performance. We would rather need a training/supervision
> of mentors including detailed feedback at the end.

Whilst that would be nice to have, it also adds another level of
bureaucracy and complexity to an already time-consuming process.

> 
> The recruiter a quite understaffed, so I would suggest to organize
> as a senior/junior mentor thing. We have really great senior
> mentors like swift, who provide always well prepared mentees. Would
> is possible to do it that way?
> 

What we can do *at the moment* is to send those recruits who are
partially prepared back to mentors. Bouncing them back to mentors is
essentially the ultimate way to tell mentors "hey, you did not do a
good job here. Try again". Which is not an unreasonable thing to do.
Mentors are supposed to be, well, mentors. If the recruit lacks
crucial information then you were clearly not a good mentor and either
self-improve or ask your recruit to find another mentor.

It's harsh, yet I think it's very effective. Recruiters,
traditionally, have been very patient trying to "teach" recruits what
mentors failed to. Obviously this does not scale very well.

Now, again, can we stay on-topic ? Fork this thread if you need to
- -- 
Regards,
Markos Chandras
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQF8BAEBCgBmBQJUajwuXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx
RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZurAH/1LCIK/EwmGeWAamBQk7IjrY
+gZNgCqKJkAwv5vjsX8MUOOQLWBoU48hLhKGJkXRTJLFZ/228EI0EhbjInPR5dvH
2eE0DPwqCJ9dsPTGkS2kzQZDJddi/VqPRJuEUs3Lqu00fPxdVXeT6InDiJYgFWdT
JTPyPjKLdu2xrVnUEBz4B7sI4OOVmi9ZkE9GhaoCyFL4ilOhQ/8qpDkezz48YyWC
1SemFvyIjphzE50KD2CKGzuulxfXlLNYYruemWg2u9kEInBy+JxRYCSqiDg1VyXl
aOVryHCfPr5ruzIrudJOW6ZCXh9yj/5cxNJ4eoJzaf7iKARs1kAW481TGlD4sow=
=s4iL
-----END PGP SIGNATURE-----

[gentoo-project] towards a more distributed model

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 11/15/2014 09:29 PM, Rich Freeman wrote:
> On Sat, Nov 15, 2014 at 10:00 AM, hasufell <hasufell@gentoo.org>
> wrote:
>> 
>> Turning it off will decrease organizational problems, make the 
>> distribution more focused and eventually more high quality,
>> because people would be able to actually work together on the
>> _core_ of gentoo (toolchain, base-system, eclasses, PM...).
>> 
> 
> Having fewer people maintaining packages will not make more people 
> work on toolchain, base-system, eclasses, portage, etc.
> 
> If somebody is actively contributing to something in critical need 
> such as one of those I'd certainly encourage the recruiters to 
> prioritize their application.  However, turning away help
> elsewhere won't help us out.
> 
> I'd suggest moving forward with building the new before getting rid
> of the old.
> 

I'm not saying you should agree with me, but I get the feeling you
didn't get the idea. I'm also answering to the other mail from
Matthias Dahl in here.

To reiterate, more gentoo _core_ developers also means:
* more different opinions
* less focus
* more bikeshed
* more conflict
* less work done?


People cannot easily group around an idea in gentoo and just start
hacking on it, because:
* although we have overlays, gentoo isn't designed to be very modular
* it's tools are not fit for more abstract approaches
* some non-core ideas/projects are already implemented in the main
tree (more or less) which are sometimes disconnected from the
community and may block progress and explicitly conflict (also on the
ebuild level, very tedious to handle) with other approaches
* it's a monolithic all-in-one distro, so anyone who likes the core of
the distro, but wants to build extensions around it has to effectively
do a full fork. Full forks are less likely, so we are not giving too
much room for experiments, enhancements and totally new ideas. Sure,
there are a few of that kind, but it took considerable effort for
these. Instead, it should be made easy... and we should try to learn
from such experiments. I don't see that happening much.

As was already pointed out: quite a lot of gentoo projects are already
moving very slowly in that very direction. They are mainly working on
themed github hosted overlays with frequent user contributions.

I may know more about ebuild writing than some community users, but it
often happens that they know way more about actual packages than me.
They rarely find the way to contribute through all these tedious
barriers we put up for them (bugzilla, cvs, getting your social status
before you can actually get stuff done)... which does NOT improve
ebuild quality.

We are imposing a workflow on people, although that workflow might
just be wrong in general or in certain cases.
That's why some gentoo projects have already a dual-workflow. Why not
make it more open?

You may say "it is open", really? Our main channel is GLEPs (uagh),
users rarely participate on gentoo dev ML.

You may say "we already allow conflicting ideas". Well yes, that's
part of the problem! We allow conflicting projects/ideas in ONE
repository That part of the GLEP never got into my head, and I know
why. It's not the way to get diversity and interesting experiments...
by giving only one box to 200 people and tell them you may practically
do what you want. It just leads to inconsistencies, fights and a big
mess, because we didn't care about proper abstraction, but about
implementing our diverse, but specific ideas right now.
No, you'd rather give everyone the same box and tell him he may do
with that as he wants. He may find out there are other people with the
exact same ideas, so there goes.


So the idea is the following:
* stop recruiting
* move clearly themed overlays/projects out of the tree which are
already practically working outside of the tree (e.g. science,
haskell, ...)
* fix the tools (never ending git story, probably a lot of work needed
on the overlay support front etc)
* focus on the core of gentoo as in: provide abstraction, tools and
the basic structure for people to do cool things. Right now we are
just focussing on keeping the ebuild machinery going, while the rest
pretty much goes downhill. Fast.
* be more open, work more with the community, not just through bugzilla
* review overlays, contribute to overlays
* have a list of high-quality overlays, maybe with a few notes about
them (is it themed? does it conflict with stuff?)
* I can't hold it but say: make ebuilds suck less, so people enjoy
contributing


But... what about quality?
Well, IMO we have lots of very poor-quality ebuilds in our tree. Not
just in overlays. That's because it's still hard to contribute, so a
small number of people have to do a LOT of work (as in: actually
writing the ebuilds) and we have no review workflow.
People who are so experienced with ebuilds like gentoo old timers with
5+ years of experience probably shouldn't write ebuilds AT ALL. Their
time is better spent just reviewing ebuilds, either by request or just
to check the quality of an overlay.

Doing things a bit more distributed will rather improve ebuild
quality, as long as we have some sort of review culture. So that's
something for the community to chew as well. But that already works in
some cases. We see it happening.
I know AUR and I think it's terrible, because I've been an arch linux
user for 2 years. So that's something we have to avoid and learn from
if we try to go into this direction.


But... what about security?
That's a more delicate matter, yeah. I can understand the concerns,
but lets start with this question first:
Why do you trust ME? You don't know anything about me. All you know is
that I probably didn't mess up too hard for the last 2 years and that
I regularly sign my Manifests/commits.
Well, a lot of overlay maintainers do as well (I once asked the
tox-overlay maintainers to gpg sign their commits and so they did).
So IMO it just boils down to community reputation and verifiable
authorship. Why care then if the guy committing is an actual "gentoo
dev" if his reputation is good?

Besides that... webapps in gentoo are in terrible shape (not blaming
anyone... tried to write such ebuilds myself, it can be awfully
complex). I'm running a gentoo server myself and I ended up installing
a lot of web apps directly from git repositories instead of the
in-tree packages. It would probably be interesting if a group from the
community will step up and clear these things out with the help of a
few gentoo devs. Or maybe a company will be interested in maintaining
a high-quality overlay of server tools and webapps? Why not? There are
already companies recruiting for gentoo experienced people and using
gentoo for servers. So why not do that?

What's more important on the security side is a different thing imo:
* our GLSA channels. They will not be obsoleted by any of these ideas.
* tools like glsa-check
* high responsiveness (in my experience a lot of overlay maintainers
are faster with fixing vulnerable packages than we are, but yeah...
this will also require more communication)

Also... no one is saying we have to remove apache from the list of
core packages.


So... why do it this way?
Because a lot of successful projects exactly operate like that.
Including VERY big projects: have a very limited number of core
developers who make the core decisions and have a strong focus. Then
have the community input and openness to get influenced both by code
and ideas while still allowing people to easily deviate from some
ideas, because we keep to the core.

I don't think we are "community-driven", just because we keep adding
community members to our "ranks". Community-driven means for me that
there is a very strong connection and communication between the core
developers and the community.
Most of the time... this doesn't ever happen and decisions are made on
our dev ML which is mostly bikeshed between gentoo devs!

In addition, if we focus on the core... we don't even have to make
that many decisions any more.

This really requires a shift of thinking and I honestly don't expect
that to happen.
But it's something that is happening around as and seems to work out
quite well (latest example is NixOS, without wanting to talk about
their technical decisions).
Some distros have programs to analyse these projects and try to
integrate some of those ideas into their own.

But I'm not really interested in fighting the decisions other people
made about gentoo ~10 years ago and write 55 GLEPs to change
something. I'd rather spend my time improving overlays or find people
(in gentoo) who think similar.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJUaUAGXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy
MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAgq6UP/ioha93yY/F/ryh8XH7mkymB
Wjwn4+L1mAV/i9YD8J70IpcbPKRmj3QQItcFVCPb8mLGFCdOr4G2LoVhRObH10IE
jqJC4QvyNL9chvsRSHvPWyFUkVGSqcgT/SlhPmtsuJt2EvSglEeC0hAXvL+YDOSL
zotuT3gETYCTnpc5xqOjkEWSSW7dHT6aA2PeXqmcNukPo4UpfJEKz06KEu7lUpER
nlWiPGL/XyxlVRB2LLNHyCHlX3dYQvZeVCXs1MFbKB1XMwNpQthWAzaJ+4ADKGVN
vd2IeByviivdkNQCc5nby6jHFZlMUiWdJJLJfdb0G39Hz2wHCXD8Crx4leqDvV3e
5OethLFq/QMV3D9gPnwMr7JWVisEAIJzCXeCyNbFnhQuA3bp9ZP6rFd8ndwt3Xzm
fQMoTjdZE279qbMbv4mrXer7/4+rIs0wPK88Bqd31HediQgsvKgHNnVx4z9gUIrn
O/rdGsV8vg9EA6bLTWBNkvXCJ38eh+8n583CXzy1FEC5esUa2y7o4iZ8MrPzUw2A
+Cc7ovSnk+bvj/XXG2ptbCC4tltuJcwFg4r+QjGEXVEpAqfh/4zgYQUIKta1ff2a
f72vvZPkR4MNC3tznWSS9SWVQL27RAzDqb4qWnRpj/sggwLcCDlYNH4WLCETkao3
G+lBZsQmmtyvyYpkrxV6
=VFTg
-----END PGP SIGNATURE-----

Re: [gentoo-project] towards a more distributed model

[Rich Freeman]

On Sun, Nov 16, 2014 at 7:23 PM, hasufell <hasufell@gentoo.org> wrote:
>
>
> So the idea is the following:
> * stop recruiting
> * move clearly themed overlays/projects out of the tree which are
> already practically working outside of the tree (e.g. science,
> haskell, ...)
> * fix the tools (never ending git story, probably a lot of work needed
> on the overlay support front etc)
> * focus on the core of gentoo as in: provide abstraction, tools and
> the basic structure for people to do cool things. Right now we are
> just focussing on keeping the ebuild machinery going, while the rest
> pretty much goes downhill. Fast.
> * be more open, work more with the community, not just through bugzilla
> * review overlays, contribute to overlays
> * have a list of high-quality overlays, maybe with a few notes about
> them (is it themed? does it conflict with stuff?)
> * I can't hold it but say: make ebuilds suck less, so people enjoy
> contributing

So, most of your post I'm perfectly fine with.

I just suggest that you do it this way:

* move clearly themed overlays/projects out of the tree which are
already practically working outside of the tree (e.g. science,
haskell, ...)
* fix the tools (never ending git story, probably a lot of work needed
on the overlay support front etc)
* focus on the core of gentoo as in: provide abstraction, tools and
the basic structure for people to do cool things. Right now we are
just focussing on keeping the ebuild machinery going, while the rest
pretty much goes downhill. Fast.
* be more open, work more with the community, not just through bugzilla
* review overlays, contribute to overlays
* have a list of high-quality overlays, maybe with a few notes about
them (is it themed? does it conflict with stuff?)
* I can't hold it but say: make ebuilds suck less, so people enjoy
contributing

THEN IF EVERYTHING IS GOING GREAT

* stop recruiting
(or more likely, shift the recruiting emphasis)

The problem with doing it the other way is that the most likely result
is that Gentoo will just die without any of the rest of this stuff
happening.  The areas you want us to focus on exclusively seem to be
the areas that almost none of the current devs actually want to work
on.

I'm not a big fan of solutions that involve abandoning something that
works somewhat well in favor of taking a chance on something new that
hasn't even been tried.  There is no reason that somebody couldn't
build all the infrastructure for overlays, reviews, etc before we stop
doing things the old way.  Just as most current devs won't work on all
the core Gentoo features you want them to work on, they won't work on
your new distributed stuff either, even if you forbid them from
working on anything else.  People work on the things that interest
them, and if that stuff interested them, they'd already be doing it.

By all means start a project to build the "New Gentoo" and recruit
people to join it.

The only thing you can really do with policy is tell people NOT to do
something.  It should really be reserved for stuff that is actively
harmful, and maintaining packages isn't harmful.

--
Rich

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[heroxbd]

hasufell <hasufell@gentoo.org> writes:

> So, I was specifically talking about a distributed model _opposed_ to
> adding new "developers" every time we are short on a team.

I don't see a problem with this: it's what we do when the team is short
of manpower.  It could be not circumvented by a new model.

b

Re: [gentoo-project] Re: Gentoo Recruiters need your help!

[heroxbd]

hasufell <hasufell@gentoo.org> writes:

> So, I was specifically talking about a distributed model _opposed_ to
> adding new "developers" every time we are short on a team.

I don't see a problem with this: it's what we do when the team is short
of manpower.  It could not be circumvented by a new model.

b

Re: [gentoo-project] Gentoo Recruiters need your help!

[Matthias Dahl]

On 15/11/14 14:43, hasufell wrote:

> We should recruit less people and instead make an effort to review other
> peoples overlays and include a list of high-quality overlays on our website.

Since every post in this thread has been (more or less) positive, I
would like to raise a word of caution though: For people who deploy
Gentoo to servers as well, trust (in the broadest sense) is an important
factor. Personally, I wouldn't feel too comfortable using a dozen or so
overlays by community members to get a proper LAPP stack together and
similar things. That is actually also one of the things I quite dislike
about ArchLinux (AUR) and Ubunutu (PPA).

On my desktop machine I only use overlays I trust that are maintained by
either official Gentoo herds/projects or individual devs.

There is a sense of trust if something is in-tree that it is maintained
by people (devs) who actually know and care about what they do and that
there are certain protocols in place to deal with security issues and
avoid violations of any kind. All of that would be hard to orchestrate
in a distributed model like suggested.

I know, reality is a bit different from that. But still, keeping only
core packages in-tree while pushing the rest into the hand of the
community... well... that is changing the picture entirely.

> The good part is: any dev can do this and it moves away from our broken
> centralized packaging model.
> In addition, this will take off workload from the recruiters team.

Probably also lowering the influx of new developers even more, if the
single purpose is to work on "core" packages, the PM, infra and the
project itself.

I don't want to start a flame war or sound in any way condescending, I
simply care about Gentoo too much that I would hate to see it take a
direction that could possibly be more harmful than helpful in the end.

Just my 2 cents...

So long,
Matthias <-- goes away now to hide somewhere save ;-)

Re: [gentoo-project] Gentoo Recruiters need your help!

[heroxbd]

hasufell <hasufell@gentoo.org> writes:

> We should recruit less people and instead make an effort to review
> other peoples overlays and include a list of high-quality overlays on
> our website.

This idea resonate with me.  High-quality overlays should include a set
of semi-official and semi-automatic overlays generated from upstream
package manager, e.g. CPAN, CTAN, CRAN, PyPI, etc.  That will reduce our
maintenance effort.

One primitive step is the "roverlay" listed in layman.

Benda

Re: [gentoo-project] Gentoo Recruiters need your help!

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]

Dnia 2014-11-14, o godz. 18:59:33
Markos Chandras <hwoarang@gentoo.org> napisał(a):

> The recruiters team needs your help once again. The manpower and time
> availability in the team is significantly low so we would welcome
> developers interested in assisting us and becoming full-time recruiters.
> Before you apply, please consider that this role requires a great deal
> of time and flexibility. I am sure you remember your reviews, which
> may have taken quite a few hours to complete. If you feel like you are
> up to the task, and committed to stay around for a while, please get
> in touch with us to discuss the first steps of your training process.
> In case of multiple applicants, we may prioritize experienced
> developers since they may require less time for training.

Maybe it'd be better to focus our efforts on reducing the retirement
and burnout rates. Of course, recruiting new people may solve the issue
of lack of manpower but Gentoo would certainly work better if existing
developers stayed active for longer periods of time. Right now, many of
them simply retire or become less and less active because of comrel
being unable to solve a few old problems.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Gentoo Recruiters need your help!

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 11/20/2014 09:35 AM, Michał Górny wrote:
> Dnia 2014-11-14, o godz. 18:59:33 Markos Chandras
> <hwoarang@gentoo.org> napisał(a):
> 
>> The recruiters team needs your help once again. The manpower and
>> time availability in the team is significantly low so we would
>> welcome developers interested in assisting us and becoming
>> full-time recruiters. Before you apply, please consider that this
>> role requires a great deal of time and flexibility. I am sure you
>> remember your reviews, which may have taken quite a few hours to
>> complete. If you feel like you are up to the task, and committed
>> to stay around for a while, please get in touch with us to
>> discuss the first steps of your training process. In case of
>> multiple applicants, we may prioritize experienced developers
>> since they may require less time for training.
> 
> Maybe it'd be better to focus our efforts on reducing the
> retirement and burnout rates. Of course, recruiting new people may
> solve the issue of lack of manpower but Gentoo would certainly work
> better if existing developers stayed active for longer periods of
> time. Right now, many of them simply retire or become less and less
> active because of comrel being unable to solve a few old problems.
> 
This is irrelevant and frankly this is a perfect flamebait which quite
a few people will happily chew. Lets not do this here again.
Please take it to comrel@ instead.

- -- 
Regards,
Markos Chandras
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQF8BAEBCgBmBQJUbj80XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx
RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZluUH/iySLDv3y64jo7B2xZFeCKFe
aprqHZEhViUMUODtWUGCtJPxbTJZjNuo5FcOvaOeqad/RD24byVpkTbZCS7spmYn
BPWtPKvE3hIIvUPqPIE2cfBMpiKCacXAIarax/LHNiZ1JVLgnCPHk5/I3oVzR6L5
wW5S0KU5OXKq4jR3cRVFVtf8k3U2y9PPB0DhB3DRnTzsLbHWXKYKLgQ+G6EBc2IV
LDCiN2kcFv2BrJcgfvLpnXmYvI3A01EAYlGpGqUzBYFk9qXHfffL2Tco7LZWNO5C
lVyaNuhjCQE0AF91bHoUT9oVm65p2VJkA4xH3kCS/GJqjKaR7Pivy/LNUhiTpzg=
=eDA3
-----END PGP SIGNATURE-----

Re: [gentoo-project] Gentoo Recruiters need your help!

[hasufell]

On 11/20/2014 08:21 PM, Markos Chandras wrote:
> On 11/20/2014 09:35 AM, Michał Górny wrote:
>> Dnia 2014-11-14, o godz. 18:59:33 Markos Chandras
>> <hwoarang@gentoo.org> napisał(a):
> 
>>> The recruiters team needs your help once again. The manpower and
>>> time availability in the team is significantly low so we would
>>> welcome developers interested in assisting us and becoming
>>> full-time recruiters. Before you apply, please consider that this
>>> role requires a great deal of time and flexibility. I am sure you
>>> remember your reviews, which may have taken quite a few hours to
>>> complete. If you feel like you are up to the task, and committed
>>> to stay around for a while, please get in touch with us to
>>> discuss the first steps of your training process. In case of
>>> multiple applicants, we may prioritize experienced developers
>>> since they may require less time for training.
> 
>> Maybe it'd be better to focus our efforts on reducing the
>> retirement and burnout rates. Of course, recruiting new people may
>> solve the issue of lack of manpower but Gentoo would certainly work
>> better if existing developers stayed active for longer periods of
>> time. Right now, many of them simply retire or become less and less
>> active because of comrel being unable to solve a few old problems.
> 
> This is irrelevant and frankly this is a perfect flamebait which quite
> a few people will happily chew. Lets not do this here again.
> Please take it to comrel@ instead.
> 

Project internal problems are neither irrelevant, nor should they be
discussed in private only.

But it's certainly not the right thread for this.