Thanks everyone! I think we’ve waited enough and have a core group of folks who are interested here. So, the first task is to brainstorm what kind of activities we want to take up. This is what I had in mind when I proposed the SIG. Please add/comment on them as necessary:
Improving awareness of current tools
The idea here is to provide a platform for developers of the many many tools to showcase their tools. So, an example activity would be regular (web?) sessions targeting end-users. These sessions will show how to install and use tools, where to get help and discuss issues, how to file bugs and feature requests.
Improving the maintenance of current tools
The idea here is to help developers improve their tools, and build communities around them to help maintain them in the long term. So, I was thinking of regular sessions targeting prospective contributors. These would encompass, for example:
- overview of the dev team and the dev pipeline (the contributing guidelines, PR review steps and so on),
- short and long term goals from a dev perspective,
- tasks where the dev team are looking for help,
- an example walk through of setting up the dev environment and perhaps making a contribution (a PR for example)
Reviewing tools
Another task that I thought would improve the maintenance + standard of current tools was for us to review them periodically. So,
- we come up with a review checklist of best practices in software development for Free/Open Source software
- members of the SIG review tools they’re interested in. (a good way to go is for dev teams to swap reviews. I.e, the team for software 1 reviews software 2 and vice versa.)
This helps different teams engage with each other and share their tips and tricks on improving tools, and it also helps devs identify areas for improvement. It’ll also help us form consensuses over best practices and so on—so the community will have a starting point when they look to contribute or start writing new tools.
The checklist will remain a living document, and perhaps each tool can be reviewed once annually (or at another frequency that can be decided on later).
Examples of checklists/reviews that we use while including software in NeuroFedora:
Here’s another example of a review: the one we did for Brian:
https://bugzilla.redhat.com/show_bug.cgi?id=1649127
You’ll see that we check quite a few things, and in lots of cases, we file issues and patches with the dev teams.
As @Shailesh_Appukuttan and other suggested, we can maintain a list of tools and their review reports as a useful source of information for the research community. It will also encourage dev teams to seek review.
Improving technical knowledge
This is simply us holding workshops to teach general technical skills/tools independent from tools. For example, on git, version control, different programming languages. While the tool related sessions would be short—an hour or two each—these can be multiple sessions over a few weeks if necessary.
There’s a lot of information out there on general computing already, so this is slightly low priority for me. I think if we work on improving the dev environments, that’ll improve general computing skills itself.
I can’t think of anything else at the moment. Thoughts/comments/additions/removals?