Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Components governance processes #70

Open
Relequestual opened this issue Nov 21, 2018 · 2 comments
Open

Components governance processes #70

Relequestual opened this issue Nov 21, 2018 · 2 comments
Assignees
Milestone

Comments

@Relequestual
Copy link
Member

As mentioned in the RC5 Retrospective document, there needs to be governance processes to manage components. I have a few ideas on how this could work, so will write those up for feedback.

@Relequestual Relequestual self-assigned this Nov 21, 2018
@Relequestual Relequestual added this to the 1.0.0 RC6 milestone Dec 3, 2018
@Relequestual
Copy link
Member Author

Email sent to GA4GH groups ga4gh-discovery-networks, discovery, ga4gh-discovery-search, beacon on 26th February 2019:

Hi All,

Please find the following two links in regards to the Schema Blocks governance discussion.

Please note these are both still just drafts (some editorial notes remain), and not necessarily accepted or approved by anyone as of yet.
Both are open for comments. Please speak your mind and feel free to ask questions.

A brief primer for the workflow diagram:
The workflow diagram is split into four sections.
The first two sections contains a valid end point, where a schema is published by a workstream or group for wider use, and doesn’t go through any formal review outside of what that group require.
The last two sections express a space where groups look to converge and standardise on schemas, looking to move to GA4GH product approved status.

A brief primer for the long document:
The overarching goal of the document is to describes the processes, workflows, and community expectations of how SchemaBlocks does work.
Much of the document outlines details on best working practices relating to working as a collaborative on Github, which will likely be familiar to technical individuals.
These processes and expectations are based on:
Best practices strongly recommended by the GA4GH product approval document
Recognising that driver projects and workstream products / projects need to have autonomy but support available
Existing similar scale schema stores / library project policies, such as the (huge) Human Cell Atlas JSON Schema store

Long document: https://docs.google.com/document/d/1cgU7Vp44VyFMxiI_nteh-jLjpoS0RUNfOoBSNN5ueZA/edit?usp=sharing

Workflow diagram: https://drive.google.com/file/d/1qKlLYS2KztNYqE8OEjYfNunnIhvAXgXT/view?usp=sharing

Thanks in advance for your feedback.

@Relequestual
Copy link
Member Author

This "more complex" workflow concept sank like a dead weight.
I will look to create a very simplified light weight several step process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant