GitHub Projects

Release Process Standard Timelines (13 Days)

date for all work items to be reviewed and closed

testing against a network mirroring mainnet with data and infra

opco pledged to announce coming emerynet testing 3 days prior to planned testing(flexible)

validators and opco testing on a shared public test-net for quality and transparency

We pledged to announce coming emerynet testing 3 days prior to planned testing

required 72 open voting period per chain bylaws

The process of validators performing a coordinated synced upgrade (watchparty)

Required testing period for validations of any changes on mainnet

all is well, done and done

Open/ Backlog - new or unaddressed items which are to be addressed during triage sessions
Up Next - triaged and placed into the assignee's que (assignee)
In Progress - Currently being solved by the assignee (assignee)
Code Complete - Work done by assignee, needs deployment to chain
Releasing - Item has been pulled into a release branch intended for deployment
Emerynet Validated - Item has been tested as part of the release branch on Emerynet
Mainnet Validated - (done) Item has been tested as part of the release branch on Mainnet

Project -The top level initiative or product set example (orchestration API)
Priority - The order in which work is to be picked up by an engineer with 1 being the highest. Priority is driven by a combination of inputs including the upgrade an item is planned for as well as other company needs and dependencies.
Release - The planned upgrade or coreEval the item is assigned to
Effort - The effort needed to complete this item, this is provided only by the engineer
Start Date - date the assignee did or estimates to start the effort
Delivery Date - date by which the assignee estimates to complete the effort
Sprint - the engineering delivery sprint for which the effort is planned
Dependency - note field for any efforts for which this effort depends
Project Milestone - defined feature, product, or effort set delivered to a customer