Comment on governance

[mikej888]

Notes on Governance to date as a result of a review of the web site.

[dill]

Would you like us to start filling in your questions in the markdown file or prefer to have them added as answers to this issue?

[mikej888]

How about filling them in in the MarkDown file and submitting the changes as a pull request?

[dill]

Sounds good. I've forked the repo onto our organisation, asked folks to make edits, then I'll send a PR back to you once we're done. Hope that sounds like a good workflow to you.

[mikej888]

That sounds good, and hopefully encourages everyone to use Git :-)

[mikej888]

dill and @mikej888 responses

Eric and I tried to dissect your Governance document and make it into a prioritised todo list/working document.

https://github.com/DistanceDevelopment/distance-consultancy/blob/priorities/Governance.md

(We chose the governance document mainly because it was the shortest and leas t technical.) Eric and I wondered if you had any thoughts on our responses and whether you thought this was a sensible way to approach this. (We are not precious, please do be critical! It's a work in progress.)

I think this is a sensible approach as I'm aware that I've generated a large number of recommendations. I also think the priorities you've set are fine.

For:

Define a support process & policy

An even lower barrier for users submitting bugs is to allow them to just raise bugs via the GoogleGroup and a Distance developer then enters this as an issue and lets the user know. One advantage of this is it can reduce the risk of users miscategorising bugs or duplicating bugs already there.

I do disagree with Mike on having two issue trackers (one for Distance and one for the Fortran code) since this difference is invisible to the user, we should instead just have one issue tracker for Distance and re-assign to the R project issue trackers if necessary (referencing between issues in the github tracker is easy).

You could have one issue tracker for Fortran as this is a stand-alone product, even though it is, as you say, invisible to the users. You could link/reassign tickets from a general Distance issue tracker as is proposed for R.

Make the citation request a requirement
beyond our control, can't really force people to cite. What are RAE/REF etc implications?

Yes, unless a project is willing to invest the time and effort to trace down people who don't respect licence terms and conditions and to bring them to account in some way, there isn't much difference between "request" and "requirement". But a "requirement" may encourage some who would not otherwise bother.