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