Open source
Seequent Evo is a geoscience data and compute platform that enables integrated workflows and collaboration across Seequent and third-party products. It powers geoscience solutions for data processing, modelling, and insight generation. These open source libraries help drive innovation and enable continuous improvements.
Head over to Seequent Evo on GitHub to explore further.
RFC (Request for Comments)
An RFC (Request for Comments) is a way of opening up a discussion around a proposed change, discuss the tradeoffs and implementation ideas, and get broader consensus on how something can be done.
Opening an RFC is done through issues on the GitHub repository that it relates to. You will find an "RFC" issue type when you go to create one.
Creating an RFC involves describing the change you want to make in as much detail as possible, including any possible implementation ideas you have, drawbacks and alternatives, and how it will be adopted by existing Evo users.
When you create your RFC, it will become "open". This opens a period where users, contributors, and maintainers of the library can get involved and contribute discussion around your idea. After a quorum of the Seequent review committee has approved your changes, the RFC will become "accepted". It may also be "rejected" if it is unsuitable for any reason.
Once an RFC becomes accepted, the authors, or anybody else, may implement it and submit the feature as a pull request. Becoming "accepted" is not a golden tick, and in particular still does not mean the feature will ultimately be merged; it does mean that the Seequent review committee has agreed to it in principle and are amenable to merging it.
Furthermore, the fact that a given RFC has been accepted implies nothing about what priority is assigned to its implementation, nor whether anybody is currently working on it.
Modifications to open and accepted RFCs can be done by editing the discussion/commenting on it. We strive to write each RFC in a manner that reflects the final design of the feature; but the nature of the process means that we cannot expect every accepted RFC to actually reflect what the end result will be; therefore we try to keep each RFC document somewhat in sync with the language feature as planned, tracking such changes via followup changes to the document.
