Hello people,
GSoC and Outreachy are coming, and I was wondering if we can have a project based on packaging/testing this time [0]? GSoC would be a great outreach method to the younger audience (students) who can take an interest in packaging and learn more about the Fedora community.
Many other orgs have mentored projects based on packaging, and therefore it is not uncommon if we bring a project on the same. We can maybe have a mentored project on some other topic, but I cannot think of any other topic for our sig.
I would love to hear everyone's review on the same topic, and I hope we are able to submit at least one mentored project for GSoC or Outreachy this time.
[0]: https://communityblog.fedoraproject.org/call-for-projects-and-mentors-gsoc-2...
On Tue, Feb 11, 2020 23:07:03 +0530, Aniket Pradhan wrote:
Hello people,
GSoC and Outreachy are coming, and I was wondering if we can have a project based on packaging/testing this time [0]?
It'd really be great if we could do either. However, it's great responsibility for us, and takes quite a bit of work. It's unfair on candidates if we take them on but are unable to mentor them well. So, off the top of my head:
- what is the project?
- 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)
- what are the skills the candidate will learn?
- 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?
- finally and probably most importantly, who has the knowledge/time/resources to mentor the candidate(s) throughout the project period, and maybe even after?
(This is all related to the "How to Propose a Project?" bit of the commblog post.)
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.
GSoC would be a great outreach method to the younger audience (students) who can take an interest in packaging and learn more about the Fedora community.
Many other orgs have mentored projects based on packaging, and therefore it is not uncommon if we bring a project on the same. We can maybe have a mentored project on some other topic, but I cannot think of any other topic for our sig.
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.
I would love to hear everyone's review on the same topic, and I hope we are able to submit at least one mentored project for GSoC or Outreachy this time.
Sure, but we must be sure of what it is we're doing and whether we have the resources to do it.
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. 2. Interest in (neuro)science? 3. How releases and versioning work. 4. Enthusiasm to send small fixes upstream to fix simple bugs/issues.
- 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.
- 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
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.
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)
- 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 :/
- Interest in (neuro)science?
+1 Some prior experience would be good, but we can make do with "interest" as the least requirement.
- How releases and versioning work.
- 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?
Hello there
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?
That's what I was aiming for...
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.
The post emphasizes to have two mentors in contrast to a single mentor. I support your view on mentoring as a team, rather than having a single mentor. But, we would have to see who all from the team are ready to spend a bit more time helping us on this.
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?
Advertising on the NeuroScience channels sounds like a great idea. It would definitely attract more students, who would be ideal for the project, in my opinion. That's how it is. But then if we don't find a suitable candidate, the Fedora project would have one less project this time, and it might reflect badly. Therefore, I guess we would have to be completely on board with this project. :D
On Fri, Feb 14, 2020 18:25:33 +0530, Aniket Pradhan wrote:
https://rescience-c.github.io/
If we do not find a suitable candidate, we don't do it. How is that?
Advertising on the NeuroScience channels sounds like a great idea. It would definitely attract more students, who would be ideal for the project, in my opinion. That's how it is. But then if we don't find a suitable candidate, the Fedora project would have one less project this time, and it might reflect badly. Therefore, I guess we would have to be completely on board with this project. :D
@major and I discussed this briefly today. We think it's a good chance to get some good work done, and maybe gain a few contributors. @major would be the main point of contact, and we can all help the candidates with different tasks.
Does that sound OK?
I'll write up a draft proposal and send it here for everyone to review before submitting it to the tracker.
Hello,
I've submitted this proposal for GSoC: https://pagure.io/mentored-projects/issue/76
Thoughts?
As you will note, while @major will be the primary contact, we will all be required to help the candidate when required and when we can. So, worth reading ;)
neurofedora@lists.fedoraproject.org
-
Aniket Pradhan -
Ankur Sinha