-
Notifications
You must be signed in to change notification settings - Fork 100
Sustainability of Clawpack
See Matthew Turk's paper, Scaling a code in the human dimension.
- How do we attract new developers?
- There is a healthy, growing rate of new subscribers/contributors to claw-users
- How open are we to new users?
- How do we encourage new users to contribute their patches?
- Should we merge the claw-dev mailing list into claw-users?
- Meetings
- [HPC]^3 and ClawDev workshops - plans for 2015/2016?
- What about organized meetings (say, for an afternoon) at conferences like SIAM CSE? This happens in practice but could be made more of a community event and advertised on claw-users.
- Google groups still a good idea, alternatives
- Mailing list
- gitter.im -> try out
- slack
- New developers
- Friendly community
- Press people to add to apps repository
- Quality control
- Require version tag
- Meetings
- Send out message about being at CSE at certain time
- Geosciences as well for GeoClaw?
- Publications
- Should we write a Clawpack 5.x paper? Where should we publish it? See https://github.com/clawpack/doc/blob/master/papers/Clawpack5x.md
- Metrics
- Publications
- Downloads
- PyPI
- Github forks/clones
- Citations
- Ohloh
- How to cite software? Notes from PDESoft 2014
- Publications
- AMS has an expectation for publications a year, things of that nature
- SIAM computational science paragraphs
- Clawpack organization say what we consider good?
- Others: Moore-Sloan, WSSSPE
- Write a Clawpack 5.x paper ***
- http://openresearchsoftware.metajnl.com
- Core developers + substantial others
- Major release write paper
- Describes major
- Where?
- SIAM SISC - Motivation, examples, PyClaw paper like, implementation must be innovative
- Journals for contributions to the open source community, Open Research Computation (Biology only), arXiv
- TOMS?
- github.com/uwescience/citing_software
- Open Research Software
- http://www.journals.elsevier.com/computer-physics-communications
- http://scicomp.stackexchange.com/questions/660/venues-for-publishing-papers-that-emphasize-software
- http://www.geoscientific-model-development.net/index.html
- http://www.scfbm.org/series/ORC
- Metrics
- Github has an API for downloads
- Establish Clawpack google account for tracking analytics
- Make a new list of applications
- Make a bibtex file for papers -> use a script or other tool to make a nice html page for this
- How to cite?
- Paper published would make this easy
See http://arxiv.org/pdf/1404.7414v2.pdf, especially the criteria on p. 19:
- Will the software continue to provide the same functionality in the future, even if the environment (other parts of the infrastructure) changes?
- Is the functionality and usability clearly explained to new users?
- Do users have a mechanism to ask questions and to learn about the software?
- Will the functionality be correct in the future, even if the environment changes?
- Does it provide the functionality that existing and future users want?
- Will it incorporate new science, theory, or tools as they develop?
- Library design vs. Framework
- Design Riemann as its own library alone, then develop time stepping above that
- Output/Input of things like the Riemann solvers
- Namespace issues are one of the largest problems
- How well documented is the code?
- What parts of the code base are not deeply understood even by core developers?
- What parts are understood well by only one person?
- Mitigation
- Software design
- Removal of leaky abstractions
- Documentation
- Language issues
- Fortran?
- Technical debt has overhead to remove, want to avoid
- Publish proceedings on this activity?
- Enable new applications or algorithms
Quote from Turk paper:
The challenge to community building that is perhaps the most worrisome is that presented by the so-called “citation economy” in science. The influence of a given piece of code is often measured by citations to a method paper, which is by definition a fixed and archived document. In 2011, a method paper for yt was published. Enzo’s method paper is still under preparation, but papers in 1997 and 2004 are often cited as references for Enzo. Through reverse-indexing of citations (supplied by ADS, Google Scholar and so on), the number of citations to these papers provides an imme- diate method of gauging the influence of the software that they describe. In the intervening time between publication of the method papers, new contributors have joined the col- laborations and contributed substantial and non-trivial en- hancements to the code base. In fact, this is not only what has already happened, but an explicit, named goal of the future of these two code bases! This results in an unfor- tunate conflict of interests between new contributors and existing contributors. It is in the best interests of existing contributors, who contributed to the code base prior to the publication of a method paper, to consolidate citations in the canonical paper; unfortunately, it is in the best inter- ests of new contributors to publish a new method paper, so that they can begin to “collect” citations. In whose inter- est is it to contribute to a code base without rewards me- diated through citations, one of the most common metrics of success in academia? I believe this is among the great- est challenges to community developed codes not only in astrophysics, but across computational science – one that will continue to grow in importance as software projects inevitably scale beyond a handful of contributors.