-
-
Notifications
You must be signed in to change notification settings - Fork 52
Let's define together what we understand by "critical" JSON Schema projects #521
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@Relequestual @Julian @jviotti I'd love to get your thoughts here. |
Makes sense! I'd object on my own Alterschema project based on those requirements though. The library behind Alterschema will be programming language specific, but I guess we can always maintain a language agnostic web UI around it. Would that be acceptable? |
Alterschema is available as a CLI though no? And that's presumably the primary way people would use it at the minute? Or do you expect they use it as a library? Because if it's the former, which would be my guess, then I think it's fine -- every tool of course is written in some language, Bowtie included -- but it's usable from any via the CLI. Of course if you use it in the host language maybe you get extra stuff (e.g. calling Bowtie from Python or whatever maybe is easier), but the spirit of language-agnostic is certainly there. |
In the issue I just provided an initial proposal to start the discussions. Regarding providing a web UI or even a CLI tool for my will be enough. |
Yeah, that's what I mean. If we clarify CLI / Web is an acceptable interface, then that sounds good to me, but I think it should be more clearly outlined ^ |
I'd like to do a trial run of the proposed and mostly approved governance process to try and best find consensus on what the "critical projects" program looks like. |
My idea with this issue is to find a common definition of things... not to define the program itself. The program should have some strategic goals, KPIs and other elements that to be defined later, once we all have the same view and consensus to proceed. |
I don't see much progress. Is it ok If I proceed with a proposal of how this program will look like? |
I'm now activly working on driving this work. |
Hello! 👋 This issue has been automatically marked as stale due to inactivity 😴 It will be closed in 180 days if no further activity occurs. To keep it active, please add a comment with more details. There can be many reasons why a specific issue has no activity. The most probable cause is a lack of time, not a lack of interest. Let us figure out together how to push this issue forward. Connect with us through our slack channel : https://json-schema.org/slack Thank you for your patience ❤️ |
I am tagging this issue |
Objective
This issue aims to start a discussion to define together what we understand by "critical" JSON Schema projects and establish the eligibility criteria and the support provided for these projects. Currently taking advantage of and supporting projects Bowtie that are not part of the Github Organization but are critical for the whole JSON Schema Ecosystem and this issue aims to standarize this situation by find a common definition, eligibility criteria and the benefits.
Defining Critical Projects (My proposal)
To qualify as a "critical" project, a JSON Schema project should meet the following criteria:
Language Agnostic: The project should be language-agnostic, ensuring its relevance to a wide range of developers working with JSON Schema, regardless of the programming language they are using.
Uniqueness: The project should offer unique and valuable functionality, avoiding direct competition with existing tools in the JSON Schema ecosystem. It should fill a gap or provide an innovative solution to a problem not adequately addressed by other projects.
Impact: Critical projects should have a significant and positive impact on the entire JSON Schema ecosystem, benefiting a large user base, or addressing key challenges faced by the community.
Open Source: Critical projects should be Open Source by definition.
Support for Critical Projects (My proposal)
The support provided to critical projects will include:
Participation in Mentoring and Contribution Programs: Critical projects will be eligible for mentorship programs to help onboard new contributors, and they will have access to resources and guidance to foster their growth.
Promotion of New Features and Updates: We will actively assist critical projects in promoting new features and updates to ensure they reach a wider audience, including cross-promotion within the JSON Schema community and on relevant platforms.
Process to join the List (To be defined)
For a project to get this status there should be a TSC voting process.
Projects to consider:
Projects lists
As soon as we have consensus on definition, benefits, accessibility and the projects part of this list we'll make the list available similarly to adopters.md.
Help us to define this together
We value your input and invite you to participate in this discussion. Please provide your feedback, suggestions, and nominations for projects that you believe meet the criteria for critical JSON Schema projects.
The text was updated successfully, but these errors were encountered: