-
Notifications
You must be signed in to change notification settings - Fork 150
Template Review Criteria
In order to maintain the quality and reliability of our Template Marketplace, we have established a set of guidelines that every template submission should adhere to. This helps ensure that users can effortlessly deploy and replicate projects for their own enjoyment and aims.
Inspired by NPM, and Dockerhub, our goal is to create a thriving ecosystem for contributors, and a smooth and understandable deployment for developers on Railway.
Every Template applying for a bounty MUST abide by these guidelines for them to be eligible for payout.
TL;DR
- Templates must deploy and work when other users deploy them
- There should be documentation when needed.
- Try to know what packages and libraries are in use in the Template
- Try not to duplicate Templates, we will rename/delete them to avoid confusion
- Templates must abide by the Railway terms of service
- If you are submitting a Template for a bounty, you must submit a PR of the repo against the Templates repo
-
1.1.1 The template must be deployable without any errors or hitches. It should integrate seamlessly with our platform's infrastructure.
- At the time of review, when deploying the Template it must result in a successful build and a successful deployment with at least one (1) accessible deployment.
- 1.1.2 Any external dependencies or services required for the template to run must be explicitly stated, with steps provided on how to configure them.
- 1.1.3 Any service within the Template must explain the configuration options within the service.
-
1.2.1 The template must be easily replicable by any user, without the need for intricate setup procedures or obscure configurations.
- If there is need for intricate setup procedures, there must be a link to a tutorial.
-
1.2.2 The template should be designed with scalability in mind. This means users should be able to deploy multiple instances if needed without collisions or conflicts.
- If certain Railway features don’t play nice with the Template, it should be documented.
-
2.1.1 Every template should come with comprehensive documentation detailing how to deploy, run, and manage the application.
- Within the Template description page, linking out
- 2.1.2 The documentation must provide context about the template's purpose, typical use-cases, and any nuances users should be aware of.
- 2.1.3 If the template integrates with third-party services or APIs, proper integration steps and alternative options (if any) should be mentioned.
- 3.1.1 Dependencies should be pinned to specific versions wherever possible, ensuring consistent behavior and reducing potential security vulnerabilities arising from unpinned or latest versions.
- 3.2.1 Submitted templates should prefer dependencies from reputable sources. Authors should be cautious about relying on lesser-known libraries or packages without thoroughly vetting them for potential security concerns or maintenance issues.
- 3.2.2 Any dependency that has known vulnerabilities, has not been maintained or updated for a significant amount of time, or has dubious origins should be avoided.
- 3.3.1 Templates should be regularly updated to accommodate for the latest patches, security fixes, or improvements in their dependencies.
- 3.3.2 In case a significant vulnerability is discovered in a widely-used dependency, template authors are expected to act promptly, updating their templates and notifying users if necessary.
- 4.1.1 Submitted templates should provide unique value, rather than simply replicating existing templates with minor changes.
- 4.1.2 If there is a conflicting Template published, duplicate templates might get renamed to be differentiated from others.
- 4.2.1 Ensure that all code, assets, and resources bundled with the template are either original, properly licensed for redistribution, or fall under open-source licenses that allow such use.
- 5**.1.1** Submitted templates must comply with the Railway Terms of Service.
- 5**.1.2** Submitting a template assumes that you have read and agreed to the Terms of Service.
- Railway's "Template Bounties" is our initiative to boost the number of high-quality templates available on our platform. By incentivizing developer maintainers with rewards, we aim to encourage the creation, upkeep, and promotion of unique, full-featured applications that elevate the standard of our Marketplace.
- Developers must recognize the progression from simple language starters to intricate applications. As we've expanded our offering, we expect contributions that reflect these advancements and serve more complex use-cases.
- All developers, regardless of previous contributions or status, are welcome to participate. Every submission will undergo the same rigorous review process.
- To begin, developers should open an issue against [the relevant repo](https://github.com/railwayapp/templates), duly filling out the provided issue form to guide the review.
- Once a template is accepted, the Railway team will begin the transfer process.
- Railway will create a repository under
railwayapp-templates, adding the contributor as a maintainer. The maintainer will then have to push the code to the root of the repo. - The maintainer will ensuring integration and continuity.
- Prior to any payouts, the template will undergo a final round of testing to ensure all components function as intended and that it adheres to all Railway standards.
- Payouts are contingent on the template passing all testing and verification stages. Any discrepancies or issues must be resolved before rewards are disbursed.
-
Once a template clears all checks, the developer will be guided through Railway's payout process. Details of the rewards, including amount and mode of payment, will be communicated transparently via email.
-
If there are two submissions on a Template submitted within the same time during the program period. Railway will execute a payout to the one that met the criteria first. Railway will credit the platform costs of developing the Template for some or all submissions.
- Developers are encouraged to stay engaged with the community, gathering feedback and making iterative improvements to their templates. This continuous enhancement approach not only augments the quality of individual templates but elevates the entire Marketplace.
While these guidelines serve as a foundation for our review process, each template will be moderated on a case-by-case basis.
We encourage creativity and innovation but also expect adherence to these principles to ensure the highest standards for our users. If you have any questions or need clarification on any point, please reach out to us via Discord or our GitHub repo (this one!).