The present text is initial food for thought for the purposes of discussion only, it does not represent the concensus view of the Developers interest group. Please consider everything here TODO target for refinement. As an example for what we hope to see here please see other interest groups for exemplar charters.
TODO See Responsibilities of Conveners.
- Star/follow this repository
- Join the Slack channel with your contribution to this community. Email secretariat@tdwg.org to get an invitation to Slack.
- Read Contributing
- Browse or add issues
- Nominate yourself (open an issue) to be a maintainer of this repository
- Read the rest of this document
There are a number of practical, personal, and theoretical advantages to building a community of developers addressing the particular needs of biodiversity science.
As in any community there are challenges and hurdles that are particular to the work that happens in that community. A shared forum for expressing those challenges and how they were overcome, or abandoned, can be both informative and therapeutic. More formally, please read our code of conduct TODO: choose/formalize code.
While many in the group would argue that open-source software and practices are the ideal to which we should strive, the group acknowledges that there biodiversity is vast, and we should not de-facto exclude tools and approaches that are partially or fully closed-source, and certainly not exclude those that are partially or fully commercial. Identifying the role of closed-source and/or commercial products, and embracing the idea that they will always exists, better positions our efforts to ensuring that those efforts more fully integrate into the broader, more open and interoperable "ecosystem" of biodiversity serving software standards. A deep understanding of closed products allows us to better communicate their impact to the people who use them and to those who mandate their use.
We have collectively shared ideas, algorithms, and by reference to standards similar outcomes in our software, but to-date we are, frankly, terrible at sharing code amongst our software. We are not just interested in sharing any code, but rather code that specifically intersects the biological domain. For example, many developers may use some specific database platform, but those platforms have nothing inherently biological about them. A very fast binary that parses scientific names, on the other hand, is an great example of what can be shared among software packages.
See specific pages about tools and libraries, code snippets and Tips and lessons learned.
Standards are arguably of little worth, or at best interesting theoretical experiments, if they are not implemented. It follows that the development process that integrates standards is logically a process that is part of standard development itself. How can we more closely integrate the two?
Biodiversity science is a field that embraces history. Similarly, we should look deep into the future. As developers we know our software will be obsolete if not minutes then days or years after it is put in motion. How do we embrace the idea of planned obsolescence? How do we create software that is adaptable over decades or millennia? If we are honest about what our software can do, then the people that use it are better prepared when it needs resources to be updated, becomes obsolete, or flat out fails.
Follow the TODO: Code of Conduct.
As developers we are technically inclined, therefore we should:
- TODO
- Use the issue tracker to initiate engagements and proposals
- Propose changes via pull requests
- Engage the slack channel (or other technical resources as they evolve)
As a means of trending our efforts to the practical and generalizable please consider the following as you engage:
- TODO: clarify, evolve, etc. the guidelines.
- Follow the guidelines for submitting issues. In general when you submit an issue imagine/state both the role and the problem and include these in the title, e.g. "As a Python developer I need a X to do Y".
- Try to keep focused on tools and questions that are inherently tied to the biological domain. There are many, many other support forums that are better, broader solutions to many questions. This will be very difficult, so please don't dissuade would-be members who initially are not following this guideline.
- Consider promoting "small" shareable code libraries and solutions rather than large, integrated specific software packages. The group does not want to become a forum promoting one software platform over another (but see Code speaks loud below). If the group gains traction, then we may create specific forums for announcements and or more casual and open conversations.
- Code speaks loud. Presenting a well thought out bit of code that demonstrates why something "needs improvement" is a wonderful contribution, it's also a good way to provide constructive criticism.
- As we communicate, strive to look deeper than the commonly espoused memes. For example "we don't want to re-invent the wheel", "we need to be more efficient", and "we need a scalable industrial solution rather than boutique solutions" aren't particularly useful statements on their own. If we don't reinvent the wheel, how will we know we got it right? If we are incredibly efficient but our outcome has no meaning, that's a problem. No technology scales to biology, and if we had only one, then it's a monoculture at an extreme risk of collapse.
- Think of this project as meta-development and promote best practices by using your best practices as you help to build the community. For example you understand that a "+1" mechanism on issues is better than adding a comment, so you use "+1".
- Don't troll ("Use VIM, not Emacs, duh!.").
How do we know we have "won"? Developers are practical people, they need to get things (software) finished. It follows that the Developers interest group can gauge success, in part, by practical outcomes:
- Ultra-diamond-delux-MEGA-wins: Pointers to fully deprecated repositories retired because shared solutions were found and are now being used, i.e. "they will know us by our trail of death". But see Monoliths.
- Number of issues opened/closed on this tracker
- Pointers to Git repositories for libraries that are dependencies to multiple software packages, e.g. using Githubs
/network/dependentstracking. - Year end reports to TDWG that identify specific software packages that are used by multiple development teams
- Shared unit test targets
- Shared feature tests (feature tests as standards)
- Development emerging around Gold standards
- The emergence of meta-software developed as an outcome of this group that uses CI/CD to facilitate interoperability
- Viewer count logs for live-coding streams on Twitch, YouTube, or Mixer
- Chat logs
- Deltas of the number of DOIs generated by the Developers community publishing in JOSS, or similar journals or DOI granting resources
- Published papers as an outcome
- Hackathons or other workshops or conferences as an outcome
- ...
The Developers interest group was conceived in part during the 2019 BiodiversityNext meeting at Leiden and presented as part of the "unconference" there. The original, now read-only document used at the conference, is at https://bit.ly/2WdQRGT.
The Developers interest group sees software as the bridge between biological standards and the people (and machines) that use them. To that end it seeks to convene a community of developers, their supporters, and managers to explore how software can improve standards and, practically, the day to day lives of the people it serves. Further, we recognize that the biodiversity developers community is disparate, and that unifying aspects of the community should lead to better personal support, more interoperable software, more rapid convergence to optimal solutions, and a richer environment to share and evolve biologically-related development practices.