Skip to end of metadata
Go to start of metadata

Overview

The GENIVI code quality and maintenance policy applies to all software projects stored under GENIVI GitHub account, unless a project is a fork where an upstream project policy clearly applies. You may also want to refer to the introduction email.

Q&M Policy 1.0


The policy is both introduced and defined in this ------> (green star)  slide deck presentation  (green star) <------- 



For more information or feedback, contact GENIVI Development Lead or GENIVI's Community Office

Checklist

In reviewing and getting all projects up to the Q&M standards, here is a briefer summary that each maintainer can also use as a checklist. These points are to be checked for each project and development lead & community manager will track it.  The review & completion of these points is however each maintainer's responsibility!  So get started on it now.  Depending on the project, the exact application of Q&M rules may need discussion, but the policy itself should be fairly clear on the freedom of implementation that exists.  Read it first, then use the checklist to get a step-by-step approach.


Maintenance Level -   (green star) ACTIVE  (star) PARTIAL or (blue star) NOT ACTIVE

LICENSE - Does the project have a LICENSE file, containing an OSI-approved open-source license, in the root directory?  Is the Copyright Holder also specified? (Both license and copyright required)
(Recommended: Each source file header contains (C) Copyright information and a one-line license reference) 

README - Does a README.md (or .rst or .asciidoc) exist in root directory?  (Recommended - use standard README format)

Bug Tracker - Is the bug/issue tracker mentioned in the README?  (If GitHub issues are enabled, that might be enough, but ideally that is still written in the README)

Mailing List - Is the appropriate mailing list mentioned in the README?

Contribution guideline - Is the preferred method of contribution (e.g. pull request) mentioned in README?  (If CONTRIBUTION file exists, refer to it in README).  Other appropriate things to document here is the branch policy (which branch is the development done on, where should PRs be sent, etc?)

Code Standard - Does the README/contribution guidelines specify the coding standard (indentation and spacing rules, newlines etc.  Note: some requirements are in Q&M Policy)
(Recommended: specify the style formally using a config file, and use automated tools like uncrustifyclang-format, or eclipse config

CI - Has continuous-integration (or more correctly, continuous build) been set up for at least the master/develop branch*?  and is the project displaying the result of that ("badge" in README, with link to details).  *Recommended is also automated builds of Pull-Requests

Static Analysis - Has a static analysis code scanner been setup in to automatically be run on every code change and is the project displaying the result of that  ("badge" in README, with link to details).  (Note the Q&M policyclarifies for which programming languages this is required)

Other - Mention any other automated code quality tooling, (for example a badge for unit test coverage, or license scanning)


  • No labels