These questions are used for the creation of the BSSC tutorials. The answers of maintainers of successful scientific software projects will be considered in the tutorials to include hands-on knowledge from projects that have faced and overcome these challenges. We are convinced that thinking about community challenges in your project can improve your community and potentially the sustainability of your whole software.

Questions:

  1. (Target community) Think about the nature of your software project. Who is your target community and how do you reach them? Are they primarily application scientists or developers? How much of your target community is already involved in your project?

  2. (Project planning) Was your project launched as part of a larger initiative or was it something that grew out of a small project (like a PhD)? How did your project find its first users after launch? Did the project grow steadily or were there sudden periods of growth?

  3. (Project activity) How active is the community in your software project today? What do you do to encourage this activity? How do new community members learn about your project? How do they approach you if they want to contribute?

  4. (Identifying obstacles to new users) Do you get feedback on why users did decide to not use your project, if so, what are common reasons? Did you make specific changes because of this feedback? Are your new users comfortable with the level of transparency that working with open-source software brings with it?

  5. (Time balance) How much work is done on the software infrastructure of your project (not directly related to scientific goals)? Do contributors also work on topics that are not immediately useful for them, if so, how is that acknowledged? Do you feel your project requires a healthy balance between infrastructure and scientific work from your maintainers?

  6. (Types of communication) Does your community know or meet each other in person or does communication mostly happen online? If they meet, do they meet as part of a specific user or developer meeting, or typically as small meetings at conferences? Would you say that your project could work without meetings in person?

  7. (Conflict management) Are you aware of situations in which participants worked on conflicting features for your software? When were these conflicts discovered? Do you have a certain policy to deal with these conflicts (e.g. time of submission, technical quality, community status of contributor)? How is this decision communicated to the contributors?

  8. (Code of conduct and atmosphere) Do you have an explicit or implicit code of conduct in your project? Was it ever necessary to enforce this code of conduct? Did you lose community members because of the culture in your project? How did you address this situation?

  9. (Credit and growth) What is the process for giving credit or even authorship to contributors of your project? Where are these rules stated? Are these rules publicly available or only known by experienced contributors?

  10. (Project relations, this questions and the ones below might be sensitive, you do not need to provide names)
    • Does your project depend on scientific upstream packages (not general-purpose ones like MPI)? What kind of communication is there between your project and the upstream projects? What kind of upstream improvements do your developers provide?
    • Are there competing software projects to yours with similar scope? What kind of communication happens between your project and the competing projects? How would you describe the atmosphere between your projects (e.g. Competitive, Collegial, Friendly)? Are there specific actions you take to maintain relationships to competing projects?

  11. (Rotating leadership) Is your project today primarily lead by the founder(s) of the project? If so, are there developers who could take over if the founder had to stop working on the project? If your project is not lead by the original founder, which circumstances and decisions were helpful in the transition? Were there mistakes that you would want to avoid next time?

  12. (Project forks) Was your project ever in danger of splitting into several forks? What lead to this situation? If a fork occured, in retrospect could/should it have been prevented? Were there any concrete changes you implemented in your community as result of this experience?