Purpose: Develop and maintain project documentation, making it readily accessible to the community
Documentation related to assets need to be provided and properly maintained. Access needs to be provided for the community and relevant
stakeholders.
| PDOC-1.1 | Does the project create a development documentation? | | 75-100 % implemented |
| PDOC-1.2 | Does the project create user documentation? | | 75-100 % implemented |
| PDOC-1.3 | Does the project create generic documentation? | | 50-75 % implemented |
Documentation maintenance
Project documentation require continuous management to stay up-to-date.
| PDOC-2.1 | Does the project provide a documentation system? | | 75-100 % implemented |
| PDOC-2.2 | Does the project maintain the documentation based on the collected user feedback? | | 75-100 % implemented |
Quality and scope of the project and asset documentation should be continuously improved.
| PDOC-3.1 | Does the project have a documentation roadmap? | | 25-50 % implemented |
| PDOC-3.2 | Does the project improve documentation through support of several natural languages? | | 0 -25 % implemented |
| PDOC-3.3 | Does the project improve intrinsic quality of documentation? | | 75-100 % implemented |
| PDOC-3.4 | Improve documents based on feedback and on evaluation | | 50-75 % implemented |
Use of Established and Widespread Standards
Purpose: Promote the use and implementation of Open Standards for product and process
Use of open standards
| STD-1.1 | Does the project implement widely accepted open product standards? | | 75-100 % implemented |
| STD-1.2 | Does the project implements standards certified by FLOSS-supporting certification entities? | | 50-75 % implemented |
| STD-1.3 | Does the project identify clearly the standards relevant to the product? | | 50-75 % implemented |
To ensure the sustained viability of a project and to improve interoperability with other projects, measures should be taken to make assets and
processes independent of proprietary solutions.
| STD-2.1 | Does the project ensure independence from specific technologies? | | 50-75 % implemented |
Purpose: Provide and implement a high quality testing process
| QTP-1.1 | Does the project ensure that the test plan covers functional testing? | | 50-75 % implemented |
| QTP-1.2 | Does the project ensure that the test plan covers non-functional testing (as demanded by the project; see below)? | | 50-75 % implemented |
| QTP-1.3 | Does the project ensure that the test plan covers different testing approaches? | | 50-75 % implemented |
| QTP-1.4 | Does the project define test cases and testing criteria? | | 50-75 % implemented |
| QTP-2.1 | Does the project conduct tests in regular intervals according to plan? | | 75-100 % implemented |
| QTP-2.2 | Does the project ensure that the test results are documented and available? | | 50-75 % implemented |
The following objectives aim on helping projects to continuously improve their test processes.
| QTP-3.1 | Does the project include test cases, test results and consider comments from stakeholders of the FLOSS project? | | 25-50 % implemented |
Licenses, Copyright and IP Management
Purpose: Ensure the project has appropriate intellectual property policy, selects appropriate licenses and copyrights and manage them satisfactorily
The text in this section does not constitute legal advice. It is important to make clear what licenses we are talking about or more precisely what components need to be taken into account. It is not just the components "in the repository" (or "in the source folders or archives"). One has to look at libraries, and the components the software will be linked to.
| LCS-1.1 | Has the project evaluated available choices against licenses already used inside the FLOSS project, or the license strategy/policy inside the company when choosing its license? | | 75-100 % implemented |
| LCS-1.2 | Does the project clearly manage its licensing conditions? | | 75-100 % implemented |
Copyright management and management of intellectual property
| LCS-2.1 | Has the project selected appropriate copyright and IP policy? | | 75-100 % implemented |
| LCS-2.2 | Does the project clearly manage its copyright and IP policy? | | 75-100 % implemented |
| LCS-3.1 | Ensure that the product does not contain or use components that are not distributed under a FLOSS license (and the licenses of the components need to be compatible) | | 75-100 % implemented |
| LCS-3.2 | The license(s) is(are) endorsed by the OSI (http://www.opensource.org/licenses) | | 75-100 % implemented |
Purpose: Provide development resources such as operating system, language compilers, development tools, communication tools, ideally all tools should be FLOSS-compliant and interoperable
Provisioning of development resources and infrastructure
| ENV-1.1 | Does the project ensure availability of software tools and environment required for development? | | 75-100 % implemented |
| ENV-1.2 | Does the project ensure availability of methodologies required for development? | | 50-75 % implemented |
| ENV-1.3 | Are there integrated management and communication tools used by the project (select the tool relevant to the project, see examples below)? | | 75-100 % implemented |
Continuous maintenance of the project environment
| ENV-2.1 | Can users suggest modifications to the environment? | | 75-100 % implemented |
| ENV-2.2 | Does the project maintain the development environment corresponding to each maintained FLOSS version? | | 50-75 % implemented |
| ENV-3.1 | Does the project gradually phase out commercial development resources and tools in favour of FLOSS equivalents? | | 75-100 % implemented |
Maintenance of defects, commits, and other contributions
Purpose: Specifically analyze the activity related to source code commits and bug reports provided to the project
Asset maintenance
| DFCT-1.1 | Does the project implement good FLOSS maintenance practices? | | 75-100 % implemented |
| DFCT-1.2 | Does the project maintain the most often used older versions of the product? | | 75-100 % implemented |
Environment for contribution of bug reports and commits
| DFCT-2.1 | Does the project provide a standardized and well-documented contributing mechanism? | | 75-100 % implemented |
Management of contributions, commits, and bug reports
| DFCT-3.1 | Does the project manage the defect reports? | | 75-100 % implemented |
| DFCT-3.2 | Does the project create and maintain a data repository of closed defects? | | 75-100 % implemented |
| DFCT-4.1 | Does the community respond efficiently to defect reports? | | 75-100 % implemented |
| DFCT-4.2 | Does the project offer specific recognition to users who report defects? | | 50-75 % implemented |
Maintenance of non-functional properties
Purpose: Specify, develop and maintain non-functional requirements for the project (e.g. maintainability, stability)
| MST-1.1 | Does the project ensure that design and code are maintainable and stable (e.g. through best practices)? | | 75-100 % implemented |
| MST-1.2 | Does the project assess the interoperability and compatibility of old and new versions of the product? | | 75-100 % implemented |
| MST-1.3 | Does the project conduct stability tests on different software and hardware systems? | | 75-100 % implemented |
Asset maintenance management
| MST-2.1 | Does the project enforce good maintainability of the software? | | 75-100 % implemented |
| MST-2.2 | Does the project maintain the most often used older versions of the product? | | 75-100 % implemented |
Purpose: Establish and maintain the integrity of the product and its releases
| CM-1.1 | Does the project identify configuration items? | | 75-100 % implemented |
| CM-1.2 | Does the project use a configuration / version management system (SVN, Git, etc.)? | | 75-100 % implemented |
| CM-1.3 | Does the project manage releases? | | 75-100 % implemented |
Tracking and control of changes
| CM-2.1 | Does the project track change requests? | | 75-100 % implemented |
| CM-2.2 | Does the project control changes in configuration items? | | 75-100 % implemented |
| CM-3.1 | Does the project manage configuration management records? | | 75-100 % implemented |
Purpose: assess cloud deployment readiness throuh quality requirements that have to be met in order to ensure that a project delivers deployable assets (binaries, images, templates) within a cloud marketplace such as AppHub.
| CLD-1.1 | Does the project provide cloud templates or images that are ready for deployment? | | % implemented |
| CLD-1.2 | Does the project provide deployable templates / images versions that are aligned with the project's releases? | | % implemented |
| CLD-1.3 | Does the project define a procedure for managing the deployable templates / images (e.g. as part of the configuration / release management)? | | % implemented |
| CLD-2.1 | Does the project provide evidence that the deployable assets function correctly? | | % implemented |
Purpose: Estimate and plan project activities
| PP-1.1 | Does the project define its scope? | | 75-100 % implemented |
| PP-1.2 | Does the project define its release plan? | | 75-100 % implemented |
| PP-1.3 | Does the project estimate efforts? | | 50-75 % implemented |
| PP-2.1 | Does the project establish the schedule or milestone plan? | | 50-75 % implemented |
Purpose: Establish and maintain Requirements
| REQM-1 | Does the project have a way to define relevant requirements? | | 50-75 % implemented |
| REQM-2 | Does the project manage requirement changes? | | 50-75 % implemented |
Purpose: Create and maintain product roadmap
| RDMP-1 | Does the project define responsibility for the roadmap? | | 50-75 % implemented |
| RDMP-2 | Does the project efficiently manage its roadmap? | | 50-75 % implemented |
| RDMP-3 | Does the project define different types of releases? | | 75-100 % implemented |
Purpose: Plan and manage stakeholder involvement
| STK-1.1 | Does the project identify its stakeholders (users, contributors, community)? | | 75-100 % implemented |
| STK-1.2 | Does the project share information with its stakeholders? | | 75-100 % implemented |
| STK-1.3 | Does the project monitor the communication traffic inside the community? | | 25-50 % implemented |
| STK-2.1 | Does the project encourage stakeholders to participate in the meetings where they are required? | | 50-75 % implemented |
| STK-2.2 | Does the project measure regularly communication inside the community? | | 25-50 % implemented |
| STK-2.3 | Does the project measure the response rate inside different communication channels? | | 0 -25 % implemented |
| STK-3.1 | Does the project measure the response level inside different communication channels and propose improvements? | | 25-50 % implemented |
| STK-3.2 | Does the project improve the management style inside the project? | | 50-75 % implemented |
| STK-3.3 | Does the project improve the communication level inside the community? | | 25-50 % implemented |
