# HG changeset patch # User František Kučera # Date 1567956486 -7200 # Node ID a549e04e160eae4fb5c0b3b7ea1a79e5432a9e41 # Parent bb745fbb9b8519e94566d3c942bd8c03e8051a37 Accept contributions diff -r bb745fbb9b85 -r a549e04e160e ssm-en.xhtml --- a/ssm-en.xhtml Sun Dec 09 01:14:18 2018 +0100 +++ b/ssm-en.xhtml Sun Sep 08 17:28:06 2019 +0200 @@ -7,13 +7,13 @@

Sane Software Manifesto

- +

<DRAFT> Please note that this is a draft version. Stay tuned for v1.0.0! </DRAFT>

- +

In respect to user freedoms, privacy, liberty, quality, mental health and world peace we create software according to these guidelines.

Free software

- +

Every piece of Sane software is also Free software.
The user has freedom to run the program for any purpose, to study and change it (i.e. has access to the source code under a free software license) and to distribute modified or unmodified copies.
there must be a big picture and software architercure described

- +

Semantic versioning

Semantic versioning is strongly recommended.
use open standards (protocols, formats) if they exist
define and publish own open standards if needed
- also standards must be semantically versioned
- should be written in machine readable format (WSDL, WADL, ASN.1, XSD, Diameter dictionary etc.) or at least formal language (Backus–Naur Form, EBNF etc.)
- also configuration should have machine readable description and should be testable by executing a command
- also standards must be semantically versioned
- should be written in machine readable format (WSDL, WADL, ASN.1, XSD, Diameter dictionary etc.) or at least formal language (Backus–Naur Form, EBNF etc.)
- also configuration should have machine readable description and should be testable by executing a command

@@ -83,16 +83,16 @@

able to be extended -
- by configuration (RegExp, SQL, XSLT, XPath etc.)
- by scripting (Guile, Bash, Python, Lua, ECMA Script etc.)
- and/or third-party plugins/modules
  - it should be easy to create a third-party module and plug it in an existing system
  - dependencies needed to write an extension (i.e. header files, API classes/interfaces) should be as small as possible (do not require large codebase to write a mere plug-in); the required dependency should contain just interfaces (method/function signatures) and data structures but no implementation (executable code)
  - by configuration (RegExp, SQL, XSLT, XPath etc.)
  - by scripting (Guile, Bash, Python, Lua, ECMA Script etc.)
  - and/or third-party plugins/modules +
    - it should be easy to create a third-party module and plug it in an existing system
    - dependencies needed to write an extension (i.e. header files, API classes/interfaces) should be as small as possible (do not require large codebase to write a mere plug-in); the required dependency should contain just interfaces (method/function signatures) and data structures but no implementation (executable code)
    +
  -
there should be public directory of extensions/scripts

@@ -130,10 +130,10 @@

depend on small and useful libraries – not on bulky application packages or libraries with large transitive dependencies

if dependency on bulky application package is inevitable, add a layer of abstraction – create a generic interface and connector and allow others to replace the bulky package with their own sane implementation

helper tools: -

if you e.g. use Bash and Perl during the build process, don't add also Python dependency, write it in Perl – or use Python instead of Perl.
Or if you use Java as your main language, consider not using Python/Perl for scripting and use Java for it

if you e.g. use Bash and Perl during the build process, don't add also Python dependency, write it in Perl – or use Python instead of Perl.
Or if you use Java as your main language, consider not using Python/Perl for scripting and use Java for it

if possible, always depend on abstract interfaces, not on particular implementations

@@ -176,17 +176,17 @@

error messages should have assigned unique error codes, so it is possible to find relevant information regardless current locale

data formats and protocols must be language/locale independent -

e.g. use decimal point instead of comma and no thousand separators for numbers, use standardized date formats
in general: everything that is expected to be machine-readable or machine-generated must be independent from current locale

e.g. use decimal point instead of comma and no thousand separators for numbers, use standardized date formats
in general: everything that is expected to be machine-readable or machine-generated must be independent from current locale

character encoding: -

always be aware of it, don't just blindly use current platform's default (because the other side might run on different platform with different default)
if given software/format/protocol has some default encoding, it must be clearly defined in its specification and this default should not be changed without changing the major version number
if there is no default, the encoding must be specified in the metadata attached (e.g. protocol headers, extended attributes on filesystem) to the actual data or at least at the begining of the data (like declaration in XML format)

always be aware of it, don't just blindly use current platform's default (because the other side might run on different platform with different default)
if given software/format/protocol has some default encoding, it must be clearly defined in its specification and this default should not be changed without changing the major version number
if there is no default, the encoding must be specified in the metadata attached (e.g. protocol headers, extended attributes on filesystem) to the actual data or at least at the begining of the data (like declaration in XML format)

the metric system should be used as default

@@ -194,22 +194,22 @@

Communication channels

use RSS/Atom or other machine readable format for: -
- security announcements
- new version announcements
- infrastructure outage announcements
- blog, documentation, how-tos etc.
- AFK events (conferences, meetings, hackatons etc.), for calendar data iCal format is strongly recommended
+
- security announcements
- new version announcements
- infrastructure outage announcements
- blog, documentation, how-tos etc.
- AFK events (conferences, meetings, hackatons etc.), for calendar data iCal format is strongly recommended
mailing list
e-mail/SMTP -
- use TLS
- use DKIM/ADSP
- use signed and encrypted messages (GnuPG or X.509)
- avoid spam and viruses, don't spam the users, don't push them to subscribe your „newsletter“ – always offer also anonymous channel like RSS/Atom
+
- use TLS
- use DKIM/ADSP
- use signed and encrypted messages (GnuPG or X.509)
- avoid spam and viruses, don't spam the users, don't push them to subscribe your „newsletter“ – always offer also anonymous channel like RSS/Atom
Jabber MUC or IRC
discussion forum
every security incident must be clearly documented and investigated – don't obscure it

Accept contributions

good quality code contributions with appropriate copyright and patent licenses or assignments should be accepted from anyone
the good quality code is defined by the project and might involve code style, idioms, design patterns, software architecture, required tests, documentation etc.
such requirements and rules should be available to the contributor before he begins; however (especially smaller) projects might communicate such code quality requirements and provide consultations and guidance during the contribution
in order to contribute, it must not be required: +
- to have an account on any particular third party service like particular e-mail or hosting provider
- to sign a contract (which includes accepting Terms and conditions) with any particular third party (e.g. source code hosting provider)
- to sign any political, religious or other proclamation or agree with it
+
in order to contribute, it might be required: +
- to have an e-mail address (but not at particular domain)
- to assign the copyright to the project and grant a free license for all patents relevant to the contribution
+
the project should record all accepted contributions and maintain a public list of all authors/contributors
the contributor must not loose the right to use or distribute the contributed code under any license (of his choice)

Open development – has public:

source code repository (versioning system), not just source code releases
plan of supported versions/branches
every release/version/branch must clearly declare the status (alpha, beta, prototype, stable, retired, deprecated…)

- - + + \ No newline at end of file