MUST request review and approval from the Open Source Review Group , meeting all checklist criteria.

[rgritti]

Project Checklist

Before presenting to the Open Source Review Group, teams/individual creators MUST meet all required criteria in this checklist:

• Complete this product analysis , which covers crafting a maintenance plan for the next six months and determines your project’s purpose. Building a Useful, User-Friendly Project #75
  • Provide some evidence, such as online research results you conducted prior to developing the project, or results of an feedback survey your conducted within relevant Zalando guilds (Open Source Guild, front-end, cloud, Scala developers, etc.), that your work is unique and does not imitate an existing, actively maintained project.
  • Remaking someone else’s deprecated project is acceptable, as you are demonstrating that your project fulfills a once-served need.
  • Usually a one-paragraph summary/list of 3-4 bullet points defining your project’s innovative features and distinct advantages is sufficient.
• Answer this security questionnaire.
• Use the MIT license only. Include an edited license file in every repository.
• Create a README covering the points provided in our standard README template . The README MUST include a note about the MIT license at the bottom. Follow the README.md template #73
• Include a MAINTAINERS file. Every project MUST have at least two named maintainers.
• Include an SECURITY. md file in the main root folder of your repository. E.g.: “If you have discovered a security vulnerability, please email [email protected] .”
• Include a CONTRIBUTING guidelines file, plus a note in your README that you welcome community contributions. Create the CONTRIBUTING.md file #74
• Estimate and provide the project’s current level of automated test coverage, and how you plan on maintaining or increasing that level over time.
  • Quality and testing levels are up to project owners/teams/maintainers to establish on a per-project basis, but the Review Group reserves the right to question those levels, and to reject for publication projects that don’t meet appropriate levels.
  • Tools available: there are several free GitHub integrations for this purpose, including Codacy (free for open source). We require that teams apply at least one.
• Perform code review. This involves two steps:
  • Contact the appropriate language/technology guild to request a code review. For instance, if your project is written in Clojure, go to #guild-clojure asking for code quality and a general code and architecture review.
  • Contact Engineering Productivity ( [email protected] ) to request a basic code review and recommendation. Important note: Engineering Productivity will NOT check your code continuously; please factor in this responsibility as part of your maintenance plan.

Contact OSS Evangelist Lauri Apple ([email protected]) for help in satisfying these criteria. In the coming months, we will announce the setup of an OSS Team that will help you.

Approvals will be given approximately one week after the presentation.

Team Tech Security will verify: “We performed a basic security review and found no severe security vulnerabilities.
”Team Engineering Productivity will verify: “We approve that the level of code quality suits Zalando´s deliverables.