| Meets | Requirement | Notes and links |
|---|
|
Ok
|
The codebase MUST be developed to be reusable in different contexts.
|
|
|
|
The codebase MUST be independent from any secret, undisclosed, proprietary or non-open licensed software or services for execution and understanding.
|
Depends upon a database with a non-open license, expect this shall change in the coming year.
|
|
Ok
|
The codebase SHOULD be in use by multiple parties.
|
Ubuntu Snap map
|
|
Ok
|
The roadmap SHOULD be influenced by the needs of multiple parties.
|
Features are commissioned by paying customers, and features are contributed by outside developers and merged. Roadmap link can be found on wekan.github.io
|
|
Ok
|
The development of the codebase SHOULD be a collaboration between multiple parties.
|
contributors
|
|
Ok
|
Configuration SHOULD be used to make source code adapt to context specific needs.
|
|
|
Ok
|
The codebase SHOULD be localizable.
|
Transifex translated
|
|
Ok
|
Source code and its documentation SHOULD NOT contain situation-specific information.
|
|
|
|
Codebase modules SHOULD be documented in such a way as to enable reuse in codebases in other contexts.
|
List of WeKan packages and list of client components. Components are not explicitly documented for reuse.
|
|
|
The software SHOULD NOT require services or platforms available from only a single vendor.
|
The database is only available from one vendor, this will change within the coming year.
|
| Meets | Requirement | Notes and links |
|---|
|
Ok
|
The codebase MUST allow anyone to submit suggestions for changes to the codebase.
|
Pull requests
|
|
Ok
|
The codebase MUST include contribution guidelines explaining what kinds of contributions are welcome and how contributors can get involved, for example in a `CONTRIBUTING` file.
|
CONTRIBUTING
|
|
Ok
|
The codebase MUST document the governance of the codebase, contributions and its community, for example in a `GOVERNANCE` file.
|
GOVERNANCE (and in FAQ)
|
|
Ok
|
The contribution guidelines SHOULD document who is expected to cover the costs of reviewing contributions.
|
CONTRIBUTING
|
|
Ok
|
The codebase SHOULD advertise the committed engagement of involved organizations in the development and maintenance.
|
There is an about section
|
|
Ok
|
The codebase SHOULD have a publicly available roadmap.
|
Roadmap and Future
|
|
Ok
|
The codebase SHOULD publish codebase activity statistics.
|
GitHub pulse and OpenHub
|
|
Ok
|
Including a code of conduct for contributors in the codebase is OPTIONAL.
|
CODE OF CONDUCT and Etiquette section in FAQ
|
| Meets | Requirement | Notes and links |
|---|
|
Ok
|
All files in the codebase MUST be version controlled.
|
Git
|
|
Ok
|
All decisions MUST be documented in commit messages.
|
Often the decision is in the PR, which is mentioned as a "fixes #5187" in the commit message. CHANGELOG links to commits and PRs with discussions.
|
|
Ok
|
Every commit message MUST link to discussions and issues wherever possible.
|
(see above)
|
|
Ok
|
The codebase SHOULD be maintained in a distributed version control system.
|
Git
|
|
Ok
|
Contribution guidelines SHOULD require contributors to group relevant changes in commits.
|
"Only send minimal changed code lines, that are related to feature or fix." in CONTRIBUTING
|
|
Ok
|
Maintainers SHOULD mark released versions of the codebase, for example using revision tags or textual labels.
|
Releases and Tags and docker tags etc.
|
|
|
Contribution guidelines SHOULD encourage file formats where the changes within the files can be easily viewed and understood in the version control system.
|
This could be a one line addition to the CONTRIBUTING file.
|
|
Ok
|
It is OPTIONAL for contributors to sign their commits and provide an email address, so that future contributors are able to contact past contributors with questions about their work.
|
|
| Meets | Requirement | Notes and links |
|---|
|
|
All contributions that are accepted or committed to release versions of the codebase MUST be reviewed by another contributor.
|
External contributions are reviewed by maintainer. There is not yet a second full-time maintainer able to review the primary maintainer's commits.
|
|
|
Reviews MUST include source, policy, tests and documentation.
|
Documentation is updated separately by the maintainer. Testing is limited to dependency checks and build success.
|
|
Ok
|
Reviewers MUST provide feedback on all decisions to not accept a contribution.
|
Maintainer, provides in the cases.
|
|
Ok
|
The review process SHOULD confirm that a contribution conforms to the standards, architecture and decisions set out in the codebase in order to pass review.
|
Not explicitly documented, yet the maintainer ensures this during review, things need to be in the correct locations in order to work.
|
|
|
Reviews SHOULD include running both the software and the tests of the codebase.
|
Maintainer tests locally if needed.
|
|
|
Contributions SHOULD be reviewed by someone in a different context than the contributor.
|
True for external contributions, not yet a second full-time maintainer.
|
|
|
Version control systems SHOULD NOT accept non-reviewed contributions in release versions.
|
No protected branch, single maintainer with commit rights.
|
|
Ok
|
Reviews SHOULD happen within two business days.
|
No explicit policy, but maintainer is prompt with reviews and merges.
|
|
|
Performing reviews by multiple reviewers is OPTIONAL.
|
|
| Meets | Requirement | Notes and links |
|---|
|
Ok
|
All of the functionality of the codebase, policy as well as source code, MUST be described in language clearly understandable for those that understand the purpose of the codebase.
|
Wiki pages for describing features; if someone raises a question, the answer usually is added to a wiki page. It would be nice to have some more visual examples pictures and videos for things like install process and drag-and-drop features.
|
|
Ok
|
The documentation of the codebase MUST contain a description of how to install and run the software.
|
Install section on the website
|
|
Ok
|
The documentation of the codebase MUST contain examples demonstrating the key functionality.
|
Under features in the wiki, e.g.: Drag and drop for mobile
|
|
Ok
|
The documentation of the codebase SHOULD contain a high level description that is clearly understandable for a wide audience of stakeholders, like the general public and journalists.
|
On the wiki
|
|
Ok
|
The documentation of the codebase SHOULD contain a section describing how to install and run a standalone version of the source code, including, if necessary, a test dataset.
|
Install section on the website
|
|
|
The documentation of the codebase SHOULD contain examples for all functionality.
|
Most of the functionality are covered on the wiki, but there are a few missing, these can be found in the changelog.
|
|
|
The documentation SHOULD describe the key components or modules of the codebase and their relationships, for example as a high level architectural diagram.
|
There is a logical directory structure, no high level architectural diagram/docs at the moment.
|
|
|
There SHOULD be continuous integration tests for the quality of the documentation.
|
Feedback indicates that the documention is very clear. There are plans to make additional documentation.
|
|
Ok
|
Including examples that make users want to immediately start using the codebase in the documentation of the codebase is OPTIONAL.
|
Wiki has good examples and Roadmap shows it in use.
|
| Meets | Requirement | Notes and links |
|---|
|
Ok
|
All codebase documentation MUST be in English.
|
|
|
Ok
|
All source code MUST be in English, except where policy is machine interpreted as code.
|
|
|
N/A
|
All bundled policy not available in English MUST have an accompanying summary in English.
|
|
|
Ok
|
Any translation MUST be up to date with the English version and vice versa.
|
English and Finnish are the only "core" translations supported for releases. Other translations are "in tree", yet contributed by the community, thus do not block releases. Perhaps this could be more clearly documented?
|
|
|
There SHOULD be no acronyms, abbreviations, puns or legal/non-English/domain specific terms in the codebase without an explanation preceding it or a link to an explanation.
|
There are some.
|
|
|
Documentation SHOULD aim for a lower secondary education reading level, as recommended by the Web Content Accessibility Guidelines 2.
|
In practice, clear language is the goal, however this is not explicitly documented. This could be a one line addition to the CONTRIBUTING file.
|
|
|
Providing a translation of any code, documentation or tests is OPTIONAL.
|
|
| Meets | Requirement | Notes and links |
|---|
|
Ok
|
For features of the codebase that facilitate the exchange of data the codebase MUST use an open standard that meets the Open Source Initiative Open Standard Requirements.
|
XML, JSON, and many others are supported, Sync
|
|
N/A
|
Any non-open standards used MUST be recorded clearly as such in the documentation.
|
No non-open standards required.
|
|
N/A
|
Any standard chosen for use within the codebase MUST be listed in the documentation with a link to where it is available.
|
|
|
N/A
|
Any non-open standards chosen for use within the codebase MUST NOT hinder collaboration and reuse.
|
|
|
N/A
|
If no existing open standard is available, effort SHOULD be put into developing one.
|
|
|
Ok
|
Open standards that are machine testable SHOULD be preferred over open standards that are not.
|
XML is preferred
|
|
N/A
|
Non-open standards that are machine testable SHOULD be preferred over non-open standards that are not.
|
|
| Meets | Requirement | Notes and links |
|---|
|
|
All functionality in the source code MUST have automated tests.
|
No test suite currently.
|
|
|
Contributions MUST pass all automated tests before they are admitted into the codebase.
|
|
|
Ok
|
The codebase MUST have guidelines explaining how to structure contributions.
|
CONTRIBUTING encourages focused contributions: "Only send minimal changed code lines, that are related to feature or fix." Further documentation in Developer guide.
|
|
Ok
|
The codebase MUST have active contributors who can review contributions.
|
|
|
|
Automated test results for contributions SHOULD be public.
|
|
|
Ok
|
The codebase guidelines SHOULD state that each contribution should focus on a single issue.
|
CONTRIBUTING encourages focused contributions: "Only send minimal changed code lines, that are related to feature or fix.", and maintainer will review and may merge exceptions if of high quality and if appropriate.
|
|
|
Source code test and documentation coverage SHOULD be monitored.
|
|
|
N/A
|
Testing policy and documentation for consistency with the source and vice versa is OPTIONAL.
|
|
|
N/A
|
Testing policy and documentation for style and broken links is OPTIONAL.
|
|
|
|
Testing the software by using examples in the documentation is OPTIONAL.
|
|
| Meets | Requirement | Notes and links |
|---|
|
Ok
|
All source code and documentation MUST be licensed such that it may be freely reusable, changeable and redistributable.
|
LICENSE. Some wekan packages have other licenses, that could be made more clear on a higher level (for instance in the License section in the README).
|
|
Ok
|
Software source code MUST be licensed under an OSI-approved or FSF Free/Libre license.
|
The MIT License
|
|
Ok
|
All source code MUST be published with a license file.
|
|
|
Ok
|
Contributors MUST NOT be required to transfer copyright of their contributions to the codebase.
|
|
|
|
All source code files in the codebase SHOULD include a copyright notice and a license header that are machine-readable.
|
Maintainer would appreciate a pull request adding this. Adding license headers is straight-forward, copyright holders are not as clear.
|
|
|
Having multiple licenses for different types of source code and documentation is OPTIONAL.
|
|
| Meets | Requirement | Notes and links |
|---|
|
Ok
|
The name of the codebase SHOULD be descriptive and free from acronyms, abbreviations, puns or organizational branding.
|
|
|
Ok
|
The codebase SHOULD have a short description that helps someone understand what the codebase is for or what it does.
|
"WeKan ® is an completely Open Source and Free software collaborative kanban board application with MIT license." in README
|
|
Ok
|
Maintainers SHOULD submit the codebase to relevant software catalogs.
|
Many, for example: Offentligkod.se, docker hub, Artifacthub, Snap store
|
|
Ok
|
The codebase SHOULD have a website which describes the problem the codebase solves using the preferred jargon of different potential users of the codebase (including technologists, policy experts and managers).
|
https://wekan.github.io/
|
|
Ok
|
The codebase SHOULD be findable using a search engine by codebase name.
|
|
|
Ok
|
The codebase SHOULD be findable using a search engine by describing the problem it solves in natural language.
|
duckduckgo
|
|
Ok
|
The codebase SHOULD have a unique and persistent identifier where the entry mentions the major contributors, repository location and website.
|
wikidata
|
|
Ok
|
The codebase SHOULD include a machine-readable metadata description, for example in a publiccode.yml file.
|
snapcraft.yaml
|
|
|
A dedicated domain name for the codebase is OPTIONAL.
|
|
|
|
Regular presentations at conferences by the community are OPTIONAL.
|
|
| Meets | Requirement | Notes and links |
|---|
|
Ok
|
The codebase MUST use a coding or writing style guide, either the codebase community's own or an existing one referred to in the codebase.
|
Follows Meteor style
|
|
|
Contributions SHOULD pass automated tests on style.
|
|
|
|
The style guide SHOULD include expectations for inline comments and documentation for non-trivial sections.
|
Neither the codbase style guide, nor the meteor guide which it reference, specify inline comments. In practice, if something is non-trivial there are code comments. This could be a one line addition to the Developer Documentation.
|
|
|
Including expectations for understandable English in the style guide is OPTIONAL.
|
This could be a one line addition to the Developer Documentation.
|
| Meets | Requirement | Notes and links |
|---|
|
Ok
|
The codebase MUST be versioned.
|
Releases
|
|
Ok
|
The codebase MUST prominently document whether or not there are versions of the codebase that are ready to use.
|
Install section on the website
|
|
Ok
|
Codebase versions that are ready to use MUST only depend on versions of other codebases that are also ready to use.
|
WeKan uses newest possible that meets the functional requirements. Maintainer takes responsibility that dependencies work, regardless of how they are labeled.
|
|
Ok
|
The codebase SHOULD contain a log of changes from version to version, for example in the `CHANGELOG`.
|
CHANGELOG
|
|
Ok
|
The method for assigning version identifiers SHOULD be documented.
|
Releases are versioned as increments are 0.01, explained in FAQ
|
|
|
It is OPTIONAL to use semantic versioning.
|
No major or minor versions.
|