Closed jpmckinney closed 4 years ago
@jpmckinney It's not true to say that there are no plans for this to be used for purposes other than OCP; there is work ongoing right now in 360Giving to separate out guidance content from the standard, in a way that may well make use of this software (depending on implementation). I also don't think it's true to say that OCP is the proponent for this repo - the ODSC team believe it's an important piece of infrastructure as standards mature.
OCP current has two options available if changes are required:
If it would help, I'd be happy to draw up some expectations around PR handling for our shared infrastructure projects (like this) that make expectations and the way that we contribute clear. It's been something that's been on our todo list forever, so I'm happy for this to be the moment that we get to it.
And, of course, there's always the option to fork the repo, if OCP feel that we're not handling it in a way that meets OCP's needs. Although, personally, I think that would be a shame!
It'd be great to draw up those expectations, as ODSC hasn't always been responsive to GitHub PRs or issues in the past (earlier Flatten Tool work comes to mind). If there's good, timely open-source collaboration, then it matters less where the repo is. Thanks!
On Jul 1, 2019, at 2:03 AM, Rob Redpath notifications@github.com wrote:
@jpmckinney It's not true to say that there are no plans for this to be used for purposes other than OCP; there is work ongoing right now in 360Giving to separate out guidance content from the standard, in a way that may well make use of this software (depending on implementation). I also don't think it's true to say that OCP is the proponent for this repo - the ODSC team believe it's an important piece of infrastructure as standards mature.
OCP current has two options available if changes are required:
Ask us to make changes (either on our own, or in collaboration with others), which in the new flow-based way of working can happen very quickly Submit a PR for us to review - as above, this can happen very quickly if it's particularly important to OCP. If it would help, I'd be happy to draw up some expectations around PR handling for our shared infrastructure projects (like this) that make expectations and the way that we contribute clear. It's been something that's been on our todo list forever, so I'm happy for this to be the moment that we get to it.
And, of course, there's always the option to fork the repo, if OCP feel that we're not handling it in a way that meets OCP's needs. Although, personally, I think that would be a shame!
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
Closing as issue opener. OCP has a fork of this repo now.
While I recognize that this repo can ostensibly be used for other targets, it's presently only used (or planned to be used) for OCP targets (OCDS documentation done, Extension Explorer planned). I'm happy for code to be merged that adds support for non-OCP targets (like how ocds-babel now supports BODS, and
ocdskit mapping-sheet
also now supports BODS). Given that OCP is the proponent for this repo, though, I prefer to have it in an org where OCP can make changes as needed.