Also important are what is expected from INCF SIGs. I list them here so everyone knows what is expected of them. (The goal is always to not be another inactive SIG :))
INCF Expectations:
SIGs should aim to hold regular meetings, take meeting notes, and report to the
INCF Secretariat three times per year. They should also plan one meeting per
year at the Assembly or another community meeting (virtual is fine given the
current situation), open to interested participants.
It is usually good to have some names on the SIG page, that’s a large piece of what people look at. I suggest you make a list of current members and we publish it with a date stated (these were the members at date XXXXXX) + link to a dynamic constantly updates page with all members. Github is probably easiest?
I think it’s probably worth mentioning that some of us are developers of these tools. I would suggest the following addition to the end of the first paragraph:
Sorry for the late reply, but I’m also quite flexible schedule-wise (even November would be possible). Happy to present whenever, assuming of course that you are looking for an informal discussion/demonstration of our development workflow and not a polished presentation
Everything in the SIG proposal sounds good to me, my github handle is @mstimberg like here.
Just some more random thoughts and related links:
if we want to go for some kind of formal review process for neuroscience software, we should probably have a closer look at the really well worked-out rOpenSci Sofware Peer Review Process. I think this might be closer to what we have in mind the CODECHECK, which is more about checking the sofware workflow for a specific publication and not so much about reviewing a software package as such.
A few more potentially relevant references for scientific computing and research software development:
In the spirit of the last article, I also remember some “best practices” guide that had incremental suggestions. Something along the lines of: “Minimal: upload your source code somewhere; Recommend: use version control”. I felt this approach was a very useful one, since many “non-export developers” in research feel like their efforts are not worth anything unless they, say, provide a git repository with a clear commit history, a test suite covering 100% of their software and running all tests automatically on CI servers. But unfortunately I do not manage to find this reference any more If anyone of you knows it, please share a link!
Haha yes, informal sessions are what we’re looking for.
We need to discuss the process/pipeline. I spoke to some folks and they suggested that a “review” would be the wrong way to go, since it feels more like a stick than a carrot. The suggestion was to have the guidelines up and encourage people to check their tools against them for compliance, and reward compliance with something—perhaps a badge or inclusion on a list that we maintain.
Thanks, I’ve added them to the issue here so we can keep track of sources we should reference:
I don’t know the link, but yes, this is how I’m writing for a start. All points are divided into “should” and “must”, which are parallel to the “recommended” and “minimal” that you’ve suggested above.
I’m hoping to have the general guidelines complete this week for a start (but then I also hoped to have them complete last week )
@Shailesh_Appukuttan has graciously agreed to co-chair the SIG, and since they’re to take over as OCNS Webmaster after my term ends, that’ll also ensure that the SIG is represented on the OCNS Board for at least the next 4 years.
For our contact details, I thought we could start rather simple—the two chairs can be the point of contact at webmaster AT cnsorg.org, and we’ll open topics here on Neurostars and ping the group as required.
Apologies for not having been active of late here (had to be away for a bit).
Thanks Ankur and everyone for all the time and effort been put into getting this SIG off the ground.
I do agree that to start off it might be better to setup guidelines/recommendations and have developers voluntarily adhere to them, and reward them with some ways - such as inclusion in a SIG approved/supported software listing. If this is done well, it might be sufficient motivation going forward for other dev teams as well. Since we might anyways wish to start small, it might be better to bring on the ‘willing’ devs onboard first.
Hello all, great to see this effort taking off. I would like to come on board as developer of the NESTML domain-specific modelling language for neurons and synapses. This language was originally an spin-off from NEST Simulator, but can operate independently, and we aim to support more simulation platforms in the future. It would be great to join this group so that we can stay up-to-date on one another’s efforts, and have some cross-fertilisation happen where possible.
If you would like to add me to the INCF page, my details are:
Could everyone take a quick peek, especially to check their affiliations? I’ve added everyone that expressed interest in participating as a member. If I’ve missed anyone, please let me know. While I did stalk everyone, I didn’t have enough information on some folks: @zova137, @gangulyanubhab98, @chaitree.baradkar.24, @maximilian.hoheiser, @ethanbb: could you please comment on the document and add your information (affiliation + web url)?
Everyone: if you haven’t yet, please tell me what your github username is so I can add you to the GitHub organisation.
@malin: do you think we could have a “Software SIG” group on Neurostars with everyone here on it? (Primarily to make it easier for me to mass poke people :D)
Hi, thank you for putting this document together, and sorry for not being more active on Neurostar (pregnancy has been draining most of my energy recently…).
Here is my Github username: amelie-aussel. I’m looking forward to hearing more from the group!
Yes, that should be easy to set up. Do we want to have any sort of privilege/trust levels, or are all that we add as members equal/allowed to post, start posts, tag people in the group? (I would suggest yes, we can always become more restrictive if we get lots of random member requests or other problems)
If anyone of you knows it, please share a link!
)