This project is an experiment to create a collaborative summary of the eResearch NZ 2022 Birds of a Feather (BoF) Open Source Software Development Dos and Don'ts

The goal is to identify rules to become successful in Open Source Software (OSS) development. In this BoF session, we will apply (somewhat simplified) OSS development methods. This will help us narrow down some common challenges encountered in OSS development. At the end of the session, you will have acquired a first hand experience with OSS development, which you will then be able to transfer to a real project.

Instead of working on software, we will edit a document containing a list of questions. New questions can be added and existing questions debated. This document will be ours, it will summarise the outcome of a group effort, which of course, is what OSS is all about.

Attendee prerequisite for active participation: a GitHub account.

• Short introductions
• Explain the process
• Demo how to make a change to document to address an issue

• Consider what topics are, or may be, of interest to attendees

• Discuss selected topics (and/or think of additional ones)
• Create Issues on the repository, one per topic
• Debate topics and record discussion points in Issue comments
• If time permits, make a Pull Request (PR) to update the document and (once merged) close one of your Issues
  • Via the GitHub UI (easy: demo)
  • (OR for experts, offline, with git and your own repo fork)
• Trivial changes (e.g. to fix a typo or change formatting) can also be made, for practice!

• Rep from each group to summarise discussion and activity
• Demo one pull-request (PR)
• Review and merge PR, to close an Issue

• What did we learn? (about OSS Development Dos and Don'ts)
• What worked well, what not so well? (in this experiment!)
• Was this an interesting experience (whether successful or not!)
• Follow-up: encourage continued addition and update of Issues and PRs over coming weeks, to see if we can end up with a useful document!

In the introduction, mention as minimally as possible:

• license, and contributor agreement
• project maintainers
• branch and merge distributed development
• code review
• conflict resolution