Contributing

Contributions to DASDAE are welcomed and appreciated, both in the form of contributions to existing packages, and in the form of new compatible packages. Before contributing please be aware of our code of conduct.

Planning

DASDAE development planning and prioritization takes place here. While it is not required to get community approval to create a new package, our efforts are more efficient, and our software will be easier for users to navigate if we collaboratively coordinate which capabilities are organized into each package (and avoid redundancy). You are encouraged to contact Eileen Martin or Ge Jin (both at Colorado School of Mines) to get the information to join the bi-weekly developer team meetings.

DASCore or other DASDAE packages

You may wonder whether a new feature you’d like to add belongs in DASCore, or if it should be part of another DASDAE package. The guiding principle is that if it does not require additional dependencies and is not particularly specialized to one sub-area of applied seismology, then it can be part of DASCore. What if the feature you’re interested in adding is generally applicable for many kinds of DAS data analysis, but requires some additional package dependency? If this is the case, open a discussion describing the feature, the additional dependency, and (optional but encouraged) other future features that may also share this dependency. Typically we’ll try to come to a clear consensus, then you can move ahead with development. If the proposed DASCore dependency addition appears to be controversial, then you will deliver a short presentation at one of the bi-weekly DASDAE developer team check-ins that should descrive the feature, the additional dependency (including approximate added size of the software required to be installed), and ideas for other features that could be enabled by this dependency. Then the developer community in attendance will discuss the proposed change and take a vote (majority approval required).

If you are interested in creating a new DASDAE package which uses DASCore as a dependency, you are not required to hold it to the same style and testing guidelines as DASCore, but you are encouraged to do so, and can use DASCore’s setup as an example. Following a common set of style and contributor workflows will make it easier for us to develop a community of DASDAE developers who can easily move between using and developing any of the DASDAE packages.

Leadership

Currently DASCore operates in BDFL mode during its initial construction phase, with Derrick Chambers leading the oversight of the master branch, but this is not intended to be the mode of operation in the future. In October 2023 at a DASDAE developer team check-in, the team will review the additions provided by contributors, and will nominate and approve a leadership team with a record of contribution to share the code management leadership responsibility.

Currently Eileen Martin and Ge Jin lead organizational activities (e.g. organize team meetings, coordinate logistics of training and tutorial activities, enforcement of community standards, approving travel and research assistantships for some contributors at Colorado School of Mines) as PI and co-PI of the NSF Geoinformatics grant that is supporting initial development of DASDAE packages. However, as the contributor community grows beyond Colorado School of Mines, after the life of the grant, these roles are intended to be rotating among community members.

Technical Aspects of Contributing

Links to information with general guidelines on how many DASDAE packages operate, including contribution workflows, style, testing, etc… will be added here. In general, DASCore can be treated as the standard mode of operation.