Contribution process for JOSS code and policies

[sneakers-the-rat]

Continuing a discussion from slack:

When this was merged, it caused a good deal of confusion, and it became clear that we need a bit more structure around changes to the code that runs joss, and while we're at it I think we might also want to make a process for proposing changes to policies as well since the distinction between policy and code can sometimes blur together given the nature of the journal.

This is a discussion issue to gather what we might want in a more formal proposal for a contribution policy, so it will be a bit barebones to start, but the initial thing I think we want is...

• For any PR that makes substantive changes, announce in either joss or development slack channel (which do we want?) and give 1 week comment time for everyone to be able to review. Bugfixes or other PRs that don't meaningfully change the code don't need the 1 week review time.
• ...? (comment below and i'll add them here)

[arfon]

Sounds like a reasonable plan to me @sneakers-the-rat !

Additions:

• We probably some kind of proviso that for dev changes, you need a 👍 from one or more of @openjournals/dev .

[cthoyt]

I've worked on two minor updates recently for 1) adding ROR support (openjournals/inara#72) and 2) adding contributor taxonomy support (openjournals/inara#87) and these both went into the Inara repository (not this one). These both effect JOSS in minor ways.

How do you think this fits in? I am not part of the JOSS Slack and don't recall seeing anywhere suggesting I should join it to make an announcement about these features

[danielskatz]

This is a good question - when changes happen that the editors don't know about, it just causes confusion, and at least in one recent case, it seems like the integration wasn't fully tested. I don't know what should be done, but perhaps we need some way that the person in JOSS who is going to make or integrate a change discusses it in advance, and also posts that it has been implemented.

[sneakers-the-rat]

I totally empathize with the way that the code for JOSS is spread out across a few different places - it works, and i can tell there's history there, but it does make coordinating releases and maintaining visibility hard.

One thing we might start with for that would be to add an overview of all the joss repos/code in the docs? there is already a statement like that here, but i think that if i was an editor i wouldn't necessarily be looking at that page when trying to understand how joss works and where i would want to watch if i wanted to be on top of changes since it's labeled as installation instructions (which it is!)

So then if we designate a few blessed repos as being the ones we give notice on, we could do a few things to increase visibility of incoming changes and invite input among the editorship:

• make a separate slack channel that's just joss announcements, and make a gh action to post there once something has received an approving review, then that signals n days for comment before merging. I usually really dislike noisy slack bots but since that is the major point of communication it seems like a good target, and we might be able to find a balance of quietness by e.g. not messaging on every commit but only when input would be welcome, etc.
• Aggregate pull request descriptions into a central changelog on the website - since these changes affect authors and sometimes reviewers too, it might be nice to have a place for people who aren't in the editor chat to be able to see what's changed and what's incoming
• Similarly, make a designated tag for issues that are proposing a change to some part of JOSS, and again since we are spread out across repos and nobody needs more github notifications, we can put that on the website so people can choose to go take a look at what might be coming.

I think there's a difference between new features, changes in behavior or policies, etc. and bugfixes tho - bugfixes we shouldn't need to seek consensus on and just resolve.