Mentioning those that I think are most involved on this side of things, apologies if not. @Patrick_Ryan @schuemie @lee_evans @msuchard @Adam_Black @Paul_Nagy
Github Projects
This is likely a much larger topic but I’ll start with the use case: The Oncology WG, among others, would greatly benefit from the ability to use the updated ‘Projects’ within Github, but given these are considered organization wide, we do not have the permissions to create one. Is there a way to enable us to do this?
There are already a few of these newer projects in the OHDSI Github but thus far any attempts to follow suit have fallen flat. I’m guessing it’s likely difficult or risky to allow this organization wide as it hasn’t been widely enabled by default and I’m wondering if there’s a way to enable a larger subset of users to create them, perhaps using permissions given with ‘Github teams’ ?
Benefits:
- the project management it enables is much more flexible, and you are able to slice up your project boards however you see fit. this would enable us to show our entire road map and each piece along with its readiness for use, what the current iteration is focusing on, the list of studies with statuses and dependencies, and so on.
- this would allow us to reference tickets from different repositories. We often have a task, ticket, or milestone that is dependant on a vocabulary issue or something else outside of the repo
I know that the GIS WG would also benefit from this utility and there is the potential for leveraging it towards the “work package repository” effort that @Andrew has been pushing for (imagine how wonderful it would be if we could create a specific issue template or label to designate a ticket as a “work package”, which resides in whichever repository it is most relevant, and the work package repo could scrape them all in an automated way)
Repo Organization
Somewhat separately this brings up a larger topic of Github repo organization best practices. For many working groups or efforts in OHDSI the different components/utilities are split up into different repos, while in others there is a single repo with often many packages, of disparate functionality, all included inside of a single repo. For an example of the latter, the OncologyWG repo current houses data documentation/ddls/scripts/CSVs for the model, an ETL that contains an R package, a set of SQL scripts, and ruby unit testing, and 4-5 other R packages for various use cases, among other things. Additionally, as mentioned above, the working group often depends on issues and work which is managed outside of that repository (vocabulary, Koios, etc.). Consequently, not only is the repo overloaded but it is also insufficient to cover all of the project management needs of the WG.
Point being, if we are going to have any sort best practices or guidelines within OHDSI for repo management we need to decide between the typical Github organization of each package being within it’s own repo, or sticking with the “working groups have a repo and shove it all in there”. Personally I would side with normal Github conventions and split up separate packages into separate repositories, but in order to effectively manage a project that spans multiple repositories, with emphases on transparency and enabling collaborative development, we would need a mechanism like the updated Github Projects described in the first point above.
Relevant link:
