docs: mandate public adopters list for growth stage projects#5
Open
dsterz wants to merge 1 commit intoneonephos:mainfrom
Open
docs: mandate public adopters list for growth stage projects#5dsterz wants to merge 1 commit intoneonephos:mainfrom
dsterz wants to merge 1 commit intoneonephos:mainfrom
Conversation
I would like to propose adding a requirement for projects to publicly list their adopters, but I suggest we place this in the Growth stage rather than waiting until Graduation. My thinking here is that bringing this transparency forward in the project lifecycle offers three major benefits for our ecosystem: * Lowers Adoption Hesitation: Transparency of adoption is an essential trust signal for prospective users. By showcasing real-world use earlier, we can help eliminate the hesitation enterprises feel when evaluating new software. * Increases Trust through Transparency: Publicly showcasing adoption proves that these are widely accepted standards, which encourages more providers and integrators to join and helps us circumvent market fragmentation. * Enables Easier Open Collaboration: When it is public knowledge who is already using the project, it becomes much easier for maintainers to communicate with them. As we note in our foundation goals, real-world adoption and feedback raise the quality and reliability of the entire stack for everyone. This places virtually no technical burden on developers but will significantly aid the TAC in proving the early success of our initiatives. Signed-off-by: David Sterz <opensource@davidsterz.de>
| ##### Acceptance Criteria | ||
|
|
||
| The TAC has not yet defined requirements for the Growth Stage. | ||
| * The project must maintain a public list of project adopters for at least the primary repository (e.g., via an ADOPTERS.md file or prominently displayed logos on the project website). |
Member
There was a problem hiding this comment.
The "primary" repository is undefined. I believe since we anyhow request a web presence (https://github.com/neonephos/guidelines-development/pull/5/changes#diff-d581ac8f08d67c132fa72c8c07f2b40c58ad6d723a299c43784623b3a08b9256R57) we could make them force adoption there?
On top of this I believe we need to define very clearly what adoption means, and at which point a project counts as adopted (I believe you have something correlated in a separate pr here #4)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I would like to propose adding a requirement for projects to publicly list their adopters, but I suggest we place this in the Growth stage rather than waiting until Graduation.
My thinking here is that bringing this transparency forward in the project lifecycle offers three major benefits for our ecosystem:
This places virtually no technical burden on developers but will significantly aid the TAC in proving the early success of our initiatives.