On Thu, Feb 13, 2020 22:11:54 +0530, Aniket Pradhan wrote:
Hey!
> - given that we are in the neuroscience domain, what skills should the
> candidate already have to be successful? (we are currently struggling
> slightly because we don't have enough volunteers from neuroscience to
> help us prioritise/organise our packaging tasks; 3 months is a short
> period to start from 0 and also do meaningful work)
1. Some knowledge of creating or working around software packages, be
it a particular language's packaging scheme or for a Linux
distribution.
So, "knowledge/experience with RPM packaging". Preferably not just
Python---lots of non-python tools on our list waiting :/
2. Interest in (neuro)science?
+1 Some prior experience would be good, but we can make do with
"interest" as the least requirement.
3. How releases and versioning work.
4. Enthusiasm to send small fixes upstream to fix simple bugs/issues.
These two are part of 1 IMO.
> - will the candidate be able to continue as a long term NeuroFedora
> contributor?
> - What must we do to improve the likelihood that they turn into
> long-term contributors?
I believe as a person creates a certain package, a sense of
responsibility grows in their mind that they are responsible for the
upbringing of the package so that others are not affected by it (at
least I feel like that). This would ensure that they would continue as
a NeuroFedora/Fedora contributor in the future as well.
The whole process of packaging is pretty fun, and amazing if people
know what they are doing, and how stuff works. Teaching them
correctly, and at a steady pace would grow their interest in the
topic.
I understand where you are coming from, but I'm afraid this does not
generalise to most package maintainers. It probably applies well to
students (I was similar during undergrad, did a bucket load of packaging
back then), but when one stops being a student, one tends to get busier
with work (advanced studies/careers/jobs take 8 hours a day 5 days a
week = 40 hours a week) and personal life (family/kids/pets/...).
So, given that the day continues to be limited to 24 hours, one has to
start making the most of their quite limited volunteering time. Most
people drop packages they're not using so they can at least take care of
the ones they do use, others just go inactive and their packages get
orphaned (you would've seen the mass retirement e-mails in the last few
months)
Bex explains this very well:
https://www.winglemeyer.org/ramblings/2019/01/07/cookie-cleanup.html#
Let's make the "long term contributor" a "nice to have" at the
moment.
If we can find a good candidate to do some serious packaging for us,
that would be worth it too maybe?
> - finally and probably most importantly, who has the
> knowledge/time/resources to mentor the candidate(s) throughout the
> project period, and maybe even after?
I wouldn't say that I have complete knowledge, but I have sufficient
knowledge of how packages work. I would be happy to mentor as well.
However, since this is the neuro-sig, I think the mentor(s) should
have some neuroscience background as well? Assuming that, I know that
they are busy people and often have not sufficient time to mentor the
candidates, and this can/might be an issue.
Otherwise, if someone else wants to volunteer, it would be pretty
great as well. :D
I won't have the time to mentor at the level GSoC requires. It's
different to mentoring in the Fedora community---it's supervision where
you become the most important point of contact for the candidate.
I think mentoring requires a detailed knowledge of packaging and build
systems---if the candidate gets stuck, the mentor is expected to help
them solve the issue.
We *could* mentor as a team, where the primary mentor remains the point
of contact (and the one who does the process etc.) while the rest of us
help with tasks. But, we must be sure that we'll be able to support the
candidate at all times, through all issues.
> Us being in the neuroscience domain complicates things a little.
We are
> right in the middle of neuroscience and software development. It is
> quite a niche gap. Not a lot of neuro folks do software development, and
> not a lot of computing folks do neuroscience. The field is not yet in a
> state where both sections are actively being trained in both skill sets.
Quite right, and that's what complicates the whole thing. Even if the
neuro-sig were to propose a project, it should be somewhat related to
what we do. A project on packaging software alone is very abstract and
can/may become a bit too complicated for the folks who are not much
experienced in software development.
> This is certainly not uncommon, but those of us that have been part of
> such projects generally tend to agree that packaging projects aren't the
> best because unless the candidate is interested in the domain of
> software that they are working with, they have no incentive to maintain
> their packages in the long run.
Maybe we can pitch the project to the candidates who are interested in
neuro-stuff, who would be pleased to help people working on their
packaged tool or library.
If we do have the resources, it is certainly worth pitching. I can
advertise on the neuroscience mailing lists and so on. Maybe there are
students out there who would like to go into neuroscience later, so it
would work well for them.
To make it more attractive, we could say that the candidate will be
encouraged to replicate a model and submit this replication to rescience
maybe? That becomes quite neurosciencey, though, so it'll depend on the
candidate's prior experience with the field.
https://rescience-c.github.io/
If we do not find a suitable candidate, we don't do it. How is that?
--
Thanks,
Regards,
Ankur Sinha (He / Him / His) |
https://ankursinha.in
Time zone: Europe/London