|
|
# Goal
|
|
|
|
|
|
We want a relatively short-time goal to work toward where people will get a reward for time they spend developing pyGWB. To that end, a good goal could be to plan to write a paper on pyGWB on approximately a 6 month timescale. There are a variety of journals that could be considered. A "minimal" journal would be JOSS, which publishes articles about open source software. However we can certainly imagine a more ambitious paper -- there were papers published in ApJ Supplements and MNRAS about bilby.
|
|
|
|
|
|
There is sufficient scope that there could be a nice paper written if the code is done well. For example, the paper can emphasize:
|
|
|
* That the code can do a variety of injections of different kinds of backgrounds.
|
|
|
* That the code interfaces with bilby and can do parameter estimation.
|
|
|
* That the code is modular and flexible in terms of enabling different kinds of cross-correlation searches in a straightforward way -- so new cross-correlation based methods should be easy to add.
|
|
|
|
|
|
This goal would (a) give people motivation to work on the project, (b) lead to a concrete milestone, (c) help organize the work -- if we identify that a certain module should be a section of the final paper, then we can assign a person to be in charge of that section/module and that person can organize the work to achieve that specific task. If the code is done well, so that it is easy for people to do their own stochastic analysis, this paper may also end up with a number of citations even outside the LVC.
|
|
|
|
|
|
Likely, the process of writing the paper would produce many of the checks and documentation that would be needed for a review.
|
|
|
|
|
|
Finally, as a philosophical comment: almost all of the code for pyGWB has been developed previously in bits and pieces as needed by members of the stochastic group. The goal for pyGWB is to collect this code and put it into a coherent package.
|
|
|
|
|
|
# Organization/Management
|
|
|
|
|
|
In order to get to that goal, we will split the work into a few concrete roles:
|
|
|
|
|
|
**Coordinators**
|
|
|
A senior person with experience in the stochastic analysis, but not necessarily any experience with python. The main responsibility is to be aware of the overall plan of what needs to be done to accomplish the final product, organize regular meetings, get reports from the module/section leads, and ask about/assign specific tasks that may be falling through the cracks or need to be coordinated between teams. This person would not be responsible for implementation details -- and in fact there may even be an advantage in keeping the coordinator somewhat removed from the nuts and bolts, so that there's not an unconscious bias toward reproducing everything that was done in Matlab.
|
|
|
|
|
|
**Module/Section leads**
|
|
|
|
|
|
People at the advanced student/postdoc level who would be in charge of 1 or 2 specific modules. They would lead a team of maybe 3-5 people working on a specific task. They are responsible for several aspects of the project:
|
|
|
|
|
|
1. Delivering a specific module of the code.
|
|
|
2. Acting as a code maintainer to approve merge requests of that module.
|
|
|
3. Acting as a section lead for the corresponding section of the paper.
|
|
|
|
|
|
**Developers**
|
|
|
Anyone in the group who is interested can being involved, can contribute code as they want and have time, and will be an author on the paper.
|
|
|
|
|
|
|
|
|
# Coordinatotrs and Module leads
|
|
|
|
|
|
Here is a list of coordinators and module leads
|
|
|
|
|
|
| Role | Person |
|
|
|
| ------ | ------ |
|
|
|
| Co-coordinator | Vuk Mandic |
|
|
|
| Co-coordinator | Nick van Remortel |
|
|
|
| Pre-processing module lead | Alba Romero |
|
|
|
| Density estimation module lead | Colm Tablot |
|
|
|
| Post-processing module lead | Pat Meyers |
|
|
|
| Injection module lead | Arianna Renzini |
|
|
|
| Data quality module lead | Kamiel Janssens |
|
|
|
| ORF module lead | Sylvia Biscoveanu |
|
|
|
| PE module lead | Katarina Martinovic |
|
|
|
|
|
|
|
|
|
|
|
|
|