Following the discussion that was started in the steering committee meeting last week, below is a formalisation of what I'd envisioned for this repository.
The below is by no means a complete or finalised idea (particularly the structure!), but it should hopefully get the ball rolling :)
Purpose
The purpose of the fireplace is to be the centralised location to discuss things related to the broader JuliaAstro organisation that does not fall under the remit of any particular package. Unlike one-off issues that could otherwise be addressed in e.g. the Slack channel, the fireplace would be for issues that need a longer time-frame or are otherwise technical in a way that would benefit from being integrated with Git(Hub) and be searchable.
@icweaver suggested to have something similar to astropy-APE, which I think captures the anticipated spirit of this repository.
Example uses:
-
Suggestions and requests for new packages that serve a purpose not already met by a (JuliaAstro) package.
-
Requests for help made by JuliaAstro package maintainers, such as asking for co-maintainers or for best practices when it comes to setting up e.g. CI or Documentation. Such issues can be formalised into documentation as needed.
-
Specific application help, for questions like "I can't work out how to do $THING like in ${OTHER_LANGUAGE:-astropy}. How can I do this in JuliaAstro?". This may then also be used to gather use-cases and inspiration for tutorials that we can put together.
-
Discussions related to things that may have broader impact, e.g. how support for a particular observatory, data format, or sub-field could be brought into JuliaAstro, and generally for tracking issues across many packages that fall under a common theme.
-
Governance and administration, should someone in the community have a proposal for how we could be organising something differently. This could include funding opportunities (?).
-
Convention and practice discussion, on how we can make our packages more interoperable and share common interfaces and approaches. Also for discussing the technicalities of needed common *Base packages.
Counter-examples / what this repository is not:
-
For help with using a particular package / technical bug reports.
-
Things related to the website, as that has its own repository that we can track such things in.
-
For general conversions, such as "what's your favourite thing you've done with JuliaAstro?". Such conversions should be encouraged, but should be held on the Discourse or Slack channel.
Structure
The use of the fireplace should be primarily in the (GitHub) Issues. Every thread of conversation can then be separated, tagged, cross-referenced, and amalgamated into milestones and projects.
There should be a CONTRIBUTING.md and CODE_OF_CONDUCT.md. The CONTRIBUTING document should structurally describe whatever consensus we arrive on in this issue for the purpose of this repository, and how someone may best organise their ideas within an existing or new issue. The CODE_OF_CONDUCT should link to the community code of conduct (as it currently does).
The README should link to the CONTRIBUTING page.
Issues should be tagged. My proposal for these would be that every issue is the product of a PURPOSE and a DOMAIN tag:
Purpose:
proposal, indicating that the issue is a feature request or a suggestion for a change -- something new.
help, indicating that the issue needs support in some way, but does not manifestly make a suggestion. If a proposal or suggestion arises from discussion in a help, then it should be opened ("promoted") as a new issue and tagged as proposal and linked together.
Domain:
packages, related to the function and (interoperable) technical use of packages within JuliaAstro.
use-case, related to achieving an application (scientific or otherwise) using the JuliaAstro ecosystem.
organisation, related to governance.
Within this system, my above examples would be tagged as:
proposal / packages (new packages) or proposal / use-case (new purpose)
help / packages
help / use-case
proposal / use-case
proposal / organisation
proposal / packages
The "null" tag applied to all others would be off-topic, indicating the issue was out of scope for this repository.
And that's it. Comments and critiques very welcomed.
Following the discussion that was started in the steering committee meeting last week, below is a formalisation of what I'd envisioned for this repository.
The below is by no means a complete or finalised idea (particularly the structure!), but it should hopefully get the ball rolling :)
Purpose
The purpose of the
fireplaceis to be the centralised location to discuss things related to the broader JuliaAstro organisation that does not fall under the remit of any particular package. Unlike one-off issues that could otherwise be addressed in e.g. the Slack channel, the fireplace would be for issues that need a longer time-frame or are otherwise technical in a way that would benefit from being integrated with Git(Hub) and be searchable.@icweaver suggested to have something similar to astropy-APE, which I think captures the anticipated spirit of this repository.
Example uses:
Suggestions and requests for new packages that serve a purpose not already met by a (JuliaAstro) package.
Requests for help made by JuliaAstro package maintainers, such as asking for co-maintainers or for best practices when it comes to setting up e.g. CI or Documentation. Such issues can be formalised into documentation as needed.
Specific application help, for questions like "I can't work out how to do
$THINGlike in${OTHER_LANGUAGE:-astropy}. How can I do this in JuliaAstro?". This may then also be used to gather use-cases and inspiration for tutorials that we can put together.Discussions related to things that may have broader impact, e.g. how support for a particular observatory, data format, or sub-field could be brought into JuliaAstro, and generally for tracking issues across many packages that fall under a common theme.
Governance and administration, should someone in the community have a proposal for how we could be organising something differently. This could include funding opportunities (?).
Convention and practice discussion, on how we can make our packages more interoperable and share common interfaces and approaches. Also for discussing the technicalities of needed common
*Basepackages.Counter-examples / what this repository is not:
For help with using a particular package / technical bug reports.
Things related to the website, as that has its own repository that we can track such things in.
For general conversions, such as "what's your favourite thing you've done with JuliaAstro?". Such conversions should be encouraged, but should be held on the Discourse or Slack channel.
Structure
The use of the
fireplaceshould be primarily in the (GitHub) Issues. Every thread of conversation can then be separated, tagged, cross-referenced, and amalgamated into milestones and projects.There should be a CONTRIBUTING.md and CODE_OF_CONDUCT.md. The CONTRIBUTING document should structurally describe whatever consensus we arrive on in this issue for the purpose of this repository, and how someone may best organise their ideas within an existing or new issue. The CODE_OF_CONDUCT should link to the community code of conduct (as it currently does).
The README should link to the CONTRIBUTING page.
Issues should be tagged. My proposal for these would be that every issue is the product of a PURPOSE and a DOMAIN tag:
Purpose:
proposal, indicating that the issue is a feature request or a suggestion for a change -- something new.help, indicating that the issue needs support in some way, but does not manifestly make a suggestion. If a proposal or suggestion arises from discussion in ahelp, then it should be opened ("promoted") as a new issue and tagged asproposaland linked together.Domain:
packages, related to the function and (interoperable) technical use of packages within JuliaAstro.use-case, related to achieving an application (scientific or otherwise) using the JuliaAstro ecosystem.organisation, related to governance.Within this system, my above examples would be tagged as:
proposal/packages(new packages) orproposal/use-case(new purpose)help/packageshelp/use-caseproposal/use-caseproposal/organisationproposal/packagesThe "null" tag applied to all others would be
off-topic, indicating the issue was out of scope for this repository.And that's it. Comments and critiques very welcomed.