On 19/02/18 11:36, Alexander Wirt wrote:
> On Mon, 19 Feb 2018, Daniel Pocock wrote:
> 
> Hi, 
> 
> being the new one here (first time as administrator of an org), I can't say
> much about the real workload of the admins. However I will try my best to
> add some input. I also can't say anything about outreach. 
> 

All 4 people listed as GSoC admins are new to this from a Debian/GSoC
perspective - so anybody else joining us will be just as welcome.

Molly has been an Outreachy admin.  I've been a GSoC admin for Ganglia
but that is very different, only 5 students and the projects in Debian
are far more diverse.


>> Nicolas and Sylvestre both resigned and gave us plenty of warning to
>> update the delegation[1]
>>
>> Molly put out a call[2] for names to put in the GSoC application but it
>> wasn't clear if that was a call for people to be part of the new
>> delegation or just the urgent request to fill out the form.
> I don't care being part of an upcoming delegation, I think gsoc is too
> important to leave it behind. 
> 

The reason I emphasize the delegation is for transparency, making it
clear to all members of the community who is involved in the decisions.
It is not a prize by any means, it is a responsibility.

At the moment, other mentors may not have been aware we were named in there.


>> The DPL also mentioned it in bits[3] but as far as I know, this comment
>> means he was just responding to queries about the process and is not
>> actively talking to potential candidates.
>>
>> Four people, including Molly and myself are in the GSoC system as
>> administrators now, our names haven't been announced and personally I'm
>> a bit cautious about not wanting to declare myself an administrator or
>> pre-empt the new delegation unless there is consensus about the way the
>> team is formed and how it wants to work.
>>
>> As mentioned in the other thread, this is something we need to clear up
>> before deciding how many projects and how to prioritize projects.
> Ack, that would be good. 

Maybe we should keep this process open until 28 February so we can
discuss it between different people in the community?


>>
>> Personally, whether I take an active role as admin may impact the way I
>> respond to student inquiries for my projects so it is also important to
>> clear up before the end of February.
>>
>> Based on my experience as a previous admin (Ganglia) and mentor, I feel
>> that a bigger admin group is needed to preserve organizational memory
>> between rounds and cope with all the deadlines (there are many more
>> deadlines for admins than mentors), maybe 3-5 admins in the GSoC system
>> and at least 2 separate admins to Outreachy (because it happens twice
>> per year and has lots of little differences that you can easily trip up on)
> I would prefer to be involved in gsoc only.
> 

Great, thanks for confirming that.

>> Having many admins in any team brings new problems but one potential
>> solution is using the Kanboard as used by the DebConf team and
>> discussed[4] in another thread on this list.  If both mentors and admins
>> use a single Kanboard (or equivalent) it will be much easier for people
>> to move around between roles and share the burden, avoiding burn-out,
>> making vacations and other things easier during the summer.  Admins and
>> backup mentors need to be able to drop into a project at any stage if
>> the main mentor has an accident or something and using a common tool
>> like that can make it more seamless.
> Some kind of tool is probably a good idea, but I am unsure which one is the
> right. Hopefully one of the more experienced admins has a good idea. 
> 

As Bruno introduced this into Renata's project, I've asked him if he
might be able to make some more comments about it.


>> Another question is whether or not we want to have any policy on admins
>> acting as mentors - if there are only 2 admins then it is harder for
>> them to mentor due to admin workload but if we operate with a large
>> admin group then it may be possible for some to mentor.  Then there are
>> questions about the conflict of interest if we have to choose between
>> projects.
> I applied as an admin to make sure that my project will get realized, so I
> can only speak for myself when I say: I would step down as admin if I
> wouldn't be able to mentor my project otherwise. 
> 

In many organizations people can do both.  I feel it is a choice for
each individual admin.


>> How do other people feel about the current status, including those of
>> you who are also listed in the GSoC system as admins today?
>>
>> Who would potentially want to be an admin, would it be more attractive
>> to you if the team was bigger and the workload distributed more?
> Distributing workload is usally a good idea :). Another option would be to
> limit the number of slots we request, if we don't have that much students (or
> only the really promising ones) the workload will also be smaller. 
> 

As commented elsewhere, the number of slots has a linear impact on the
amount of work at each deadline.

However, the number of deadlines and the feeling of responsibility is
always there, even with only 5 slots.  This impacts the way admins plan
their holidays, etc, whether we have 5 students or 10 or 25.

Another idea for counting slots: if many projects use the same skill
(e.g. Python), the mentors can share that workload more easily.  If
every project is using a different skill (e.g. one Python, another using
Go, then Ruby, JavaScript, Java, C, ...) it can be stretched to the
point where mentors and admins can't easily help other projects.

Regards,

Daniel

Reply via email to