Open mcleo-d opened 4 years ago
mcleo-d
commented
4 years ago Following a conversation with @paulwhitby, @mcleo-d to work with @udalmik on the first assessment of the Plexus activation status. Then, @mcleo-d and @paulwhitby to meet on Monday 24th February to assess and raise team stories to bridge gaps.
mcleo-d
commented
4 years ago Thanks for your time today @paulwhitby.
It was great running through and updating the activation stories! 🚀🚀🚀
Following a conversation with @paulwhitby, @mcleo-d to work with @udalmik on the first assessment of the Plexus activation status. Then, @mcleo-d and @paulwhitby to meet on Monday 24th February to assess and raise team stories to bridge gaps.
mcleo-d
commented
4 years ago @paulwhitby - Can we add the Plexus activation to the PMC agenda for the life of this epic? It would be great to have it as a running theme until active 👍
Description of Activation Epic
Virtually all FINOS hosted projects are expected to strive towards, and ultimately attain, Active status.
This indicates to potential consumers that the project has reached a level of maturity, both functional and non-functional, that it is suitable for production use.
A full description of FINOS project activation is linked below where more detail can be found.
Initiating Activation
For a project to become Active, it must be reviewed and the change formally approved by the PMC of the Program the project is hosted in.
Any project team may initiate this approval process at any time, which involves:
Approval Process
Increased visibility and positioning in FINOS web resources, marketing and Community building efforts like meetups, blog posts, etc. #149
The Project adopts best-of-breed standards of distributed software development, including but not limited to:
If Project Team choses not to use the FINOS provided Open Developer Platform (ODP), a comparable SDLC should be adopted and made available.
#150The Project code/documentation release process automated or at lest well documented.
If code is published, publicly redistributed release binaries should be listed or referred to in the documentation (e.g. under the FINOS namespace in an artefact repository or package manager, e.g. NPM, Maven Central, etc.)
#151- No OWASP Top 10 warnings are present in the code
- No long-standing medium or higher vulnerabilities (2+ months) and proper security disclosure processes
- Any cryptographic functions and key lengths used within the software should be identified and vetted with Foundation's legal counsel in order to request compliance with U.S. Export policy.
#152The README.md must include or reference up to date:
- end user docs, including a description of the software, feature overview, installation & configuration instructions
- developer docs, including links to other external systems (further docs, wiki, CI & validation tools, artefact repository, change log / history, etc.)
- where possible badges (e.g. from shields.io) are encouraged
- sample code explaining how to use the project, library, standard, SDK, etc.
#153(*) transparent governance model is when a project’s discussions, minutes, deliberations, project plans, issue tracking plans for new features, and other artefacts are open, public, and easily accessible in the FINOS Project Infrastructure or FINOS sanctioned external system.