Can we have quarterly releases of ENVO?

[matentzn]

I really do not want to be annoying, please read this issue with the great appreciation I have for ENVO and its amazing team. There has not been a release for more than 1 year. There are 34 open pull requests. Environments are becoming more and more important now for everything, and I need to make some decisions about how to handle it. I want to use ENVO everywhere, but we need a much, much faster turnaround for releases. I understand that you may not have the resources, so here my offer:

How can I help to get a process going that enables ENVO releases every 3 months?

I am happy to help any way I can, even doing the releases, fixing bugs, etc.. But there is now a lot of pressure for staying current and having faster turnarounds. Alternatively, it is also ok to say clearly that you do not want to have more frequent releases for one reason or another, or do not accept pull requests. At least then we can plan around that decision!

Thank you all.

[pbuttigieg]

We could have an auto-release schedule for more regular deployment.

For the PRs - I think we need monthly mini-hackathons to deal with the curation and then close them. Submitters can attend if they are invested; if they just need a term in they can leave the rest to us. This worked well with getting terms up to a good level during our ESIP work.

The definitions in PRs must almost always be rewritten for clarity, rigour, ontological fitness, and subject-matter accuracy. Placement and axiomatisation too. Going back and forth with submitters takes too much - we have to decouple training from production.

[pbuttigieg]

There are also dependency issues with some branches (PCO, ECOCORE, etc ) which slow things down. Henceforth, I'm just creating terms in ENVO when they're needed and not importable. We can obsolete and replace them if those ontologies revive.

It's too cumbersome to keep switching editing environments and settings (in Protege etc ) when editing several ontologies. If there's a way to make that smoother, it would also help.

[matentzn]

Awesome, thanks.

I can help with the following:

1. Create the releases in regular intervals. Can I just start now? What is the SOP for that process, just running a release, making a PR, waiting for a sign off, merge make a github release?
2. Facilitate comms with dependencies. I have good ties into all of these (PCO, ECOCORE) and I am happy to make this quicker. Just tag my name with can you help and I will get it done.
3. Switching between multiple ontologies will be easier with the next Protege release, as per this PR. I am talking to @matthewhorridge to get a release out soon.

If you can take care of setting up these regular ENVO calls to work on PRs that would be awesome, but in the meantime, it would still be could if you could allow technical fixes to be merged without needing a review by you (like #1324, by assigning one of your team members, I can also do it).

Lastly I think we need to take training people writing good definitions seriously. We have a format for that (OBO training, every two weeks). If you would be able to commit to providing 1 hour of training just about writing good definitions, then I could take care of the rest - writing better materials, distributing the training videos and getting people to taking this task more seriously.

[matentzn]

All that said, are you ok with me running a release now, end of this week?

[kaiiam]

Thanks again @matentzn for offering to help. It's always a balance of quality vs timeliness on PRs. I worry ENVO isn't moving fast enough to completely satisfying community needs. I think it would be helpful for us to discuss some of these issues a governance meeting. E.g. standards for PRs how can we decide if they are good enough or not (regarding defs), who can decide to approve and merge, how often we have releases etc.

[pbuttigieg]

@matentzn - I think the ENVO makefile and build process is in need of an update to what the current ODK status is. We can do that after this release.

Let me check across the PRs and see what we can merge.

[matentzn]

Sounds good, happy to migrate ENVO to ODK. Some pretty cool new features in there as well as better metadata and QC. Let me know when I can run a release, I will do it this time if that's ok @kaiiam to get a sense of what would be required to migrate it to full fledged ODK.

[kaiiam]

Sounds like a plan. I've used ODK many times, but never migrated an existing repo to ODK standard. One obvious discrepancy with ENVO vs ODS standard is the src path

in ENVO it's src/envo in ODK repos it's src/ontology/. This might be rather trivial but it could break some code in the makefile, which would need updating too. I remember @matentzn you previous said revamping ENVO to ODK would take you a couple days of work. Just my two cents.

[cmungall]

I fully support this work, and yes I think that any technical PRs you have can be merged without review. I created an issue label 'technical' (not sure if there is a better standard here), and added this issue to it

I see some discussion here already that could be broken into more granular technical issues which Nico could help with (migrate to new ODK, consider rename of src folder)

[kaiiam]

See https://github.com/EnvironmentOntology/envo/issues/1335 for ODK issue and discussion going forward.

[pbuttigieg]

I fully support this work, and yes I think that any technical PRs you have can be merged without review. 

No, they need review. If they are obscure or poorly documented changes that we need clarification on, they should not be merged until we have clear documentation available.

[ddooley]

Any prognosis on a new release? I know last ENVO curation zoom was devoted to governance discussion. But what is the to-do to get next release out the door?