You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 5, 2024. It is now read-only.
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.
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:
Preparing an information packet demonstrating that they've met the requirements for activation (see below for details)
Submitting the packet to the appropriate PMC mailing list, requesting an activation vote.
Approval Process
Activation votes are performed by the PMC using the Foundation's standard Decision Making Mechanism, and only after any outstanding questions or clarifications are answered by the project team.
Activation (promotion to Active State)
What it means for consumers?
The Project is high quality, mature from a codebase and community dynamics perspective. The Project produces valuable releases to solve a useful business problem for our Community. #148
What it means for the Project Team?
Glory in the Community Increased visibility and positioning in FINOS web resources, marketing and Community building efforts like meetups, blog posts, etc. #149
QUALITY & SECURITY
Development Process
The Project adopts best-of-breed standards of distributed software development, including but not limited to:
semantic versioning
tagging / branch protection
continuous integration ("CI") and continuous delivery ("CD") where applicable
If Project Team choses not to use the FINOS provided Open Developer Platform (ODP), a comparable SDLC should be adopted and made available.
The 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.)
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.
Project has active participation from 2+ independent individuals and/or organizations; Ideally Project Team members who make contributions in connection with their employment are doing do as part of their regular job duties. #154
Project Team
Project Team has/have demonstrated active involvement in PMC and have demonstrated commitment to furthering overall Program goals #155
License
Project must not have dependencies which effectively restrict how the project may be distributed or deployed and must not depend on any proprietary third-party components for their core functionality. #156
Trademark
Community is using a different established Project name or original contribution trademark is owned by FINOS. All Project related websites and assets are owned and hosted by FINOS. #157
ROADMAP & RESOURCES
Progress
Project has progressed against its public roadmap during incubation; roadmap is aligned with, and where applicable incorporated into, the overall program roadmap or backlog #158
Versioning
Project software is production grade and ready for large scale consumption. 1.0.0 version was released and announced it to the announce@ mailing list. #159
Roadmap
Projects share and work to a public roadmap, aligned with the overall program roadmap. #160
FINOS Support
Project Team is largely self-sufficient, requiring minimal operational support from FINOS to govern the maintain the project. FINOS support switches to strategic growth of the Project in the Community. #161
GROWTH & ADOPTION
Usefulness
The Project demonstrably solves a real life use case in the Community. Evidence of adoption beyond the contributing individuals or firms (e.g., in the form of download statistics, listing known deployments or implementations, etc.) #162
Status Badging
Project Team commits to adopt the FINOS Active badge in the README.md once PMC approves activation properly signal adopters the new state of the Project #163
HYGIENE & OPERATIONS
Compliance
The appropriate license text is included in each source file's header. See details and template #164
Community Inquiries
Community inquiries on the project channels (mailing lists, issues and pull requests, etc) are generally promptly answered #165
Meeting Hygiene
If the project meets regularly on-line, the Project Team has demonstrated a track record of publishing and distributing agenda no less than 24 hours before the meeting, and publishes meeting minutes after calls. #166
Transparency
Project Team has adopted a transparent governance model(*) consistent with FINOS Community governance. Work for new contributors is organized into issues within a public issue tracking system, as appropriate, tagged as "Good First Issues" #167
(*) 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.
The text was updated successfully, but these errors were encountered:
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.
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.
@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 👍
…/plexus-interop:master to db-contrib/develop
* commit '29a929472e88055ca43b884ee39ed25a85d2ede3':
AAP-18914: Improved logging of clients
AAP-18914: Removed logic of cancelling message propagation. Improved logic of Accept and TryRemove connection methods
AAP-18914: Fixed hanging connections after disconnect on ResolveTargetConnectionAsync
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
The text was updated successfully, but these errors were encountered: