Description of process used to work towards an article describing. Might be useful/interesting for others who want to crowdsource in this way to have this information.
Visioning to collect from session participants a list of features of great bioinformatics open source software communities
Used "visioining" for the group to discuss this issue in many parallel discussions. In final 1-on-1 chat, partners wrote down on index cards the key features they feel are shared by great open source bioinformaitcs software communities.
Aidan collected these cards at the end of the session, and put this list online in an Etherpad (removing redundancy, and doing some editing of the 'features') for use in the next day's session. The file "2015_07_10_visioningSessionCardsTranscribed.md" contains Aidan's initial transcription of all the cards. The file "2015_07_11_possibleOSTDiscussionTopics.md" contains the edited list of features taken from these transcripts.
We used OST asking the group to split into groups to discuss:
- why these features are important i.e. what they bring the community
- challenges at achieving/making the features happen
- tips for establishing and maintaining the features
We're keen to open contributions to this manuscript from a diverse group of people, and to include examples taken from a wide range of different Open Source projects.
We've discussed how best to bring people on board.
Initial idea was to ask people to either Tweet at me @AidanBudd, or email me, with names and email addresses, then I would mail everyone once we had lots of these, and then invite them to have privileges to contribute directly to https://github.com/aidanbudd/bosc2015 .
We also considered inviting people to give their details by filling out a GoogleForm, however we would only do that when there were also an option for people to give their details without interacting with Google.
It was suggested we allow anonymous contributions; if/when we try and publish it, we'd need people to then state their name and affiliation associated with their github handle so we could assign authorship.
It was also suggested that we try using fork/pull model, rather than giving everyone privileges to edit the repo directly. Some concern, however, if that might set a barrier for contribution that would be too high for some people i.e. a mixture of outside their experience/skill set and/or too much hassle to set up.
We decided however to stick with the fork/pull model, while also giving people the option of contacting Aidan, so that those who find the github fork/pull process a problem, can still contribute.
This will be Aidan's first time using fork/pull, so he's not sure how easy it is to keep track of the order of contributions.
We'll initial try asking people to indicate their contribution order by editing a file listing people's names and affiliations, in the order the contributions are made.