+++ /dev/null
-Introduction
-============
-
-First off, thank you for your interest in Muddle! We, your fellow
-contributors, welcome contributions of all kinds and types from anyone
-anywhere.
-
-Contributing to Muddle
-======================
-
-In addition to this document please read and follow the Code Of
-Conduct and Attestation, found elsewhere in this repository. If you
-will submit contributions of code or documentation please also read
-GNU Coding Standards: <https://www.gnu.org/prep/standards/>. Reading
-through this information helps to set basic ground rules, both social
-and technical, and make sure that everyone is on the same page.
-
-Where to go for help
-====================
-
-We can be found in `#muddle` on `irc.freenode.net`.
-
-Discussion
-==========
-
-It's important to keep communication lines open. Please discuss major
-changes and enhancements that you wish to make in advance with your
-fellow contributors.
-
-Submitting Patches
-==================
-
-First you will need to set up the git version control system. Your
-GNU/Linux distro has probably already packaged it for easy
-installation.
-
-Read through the Attestation document, found elsewhere in this
-repository, and run the commands mentioned in there to set up your
-name and email address.
-
-Be sure to review the information in the rest of this file, then make
-your changes and commit locally, using `git commit --signoff` to add
-your `Signed-off-by` to *each* commit.
-
-Once ready, use `git format-patch origin/master` to generate patches
-for your commits. Email those to <j@jxself.org> for review.
-
-Basic Information
-=================
-
-- A commit should address one, and only one, concern. For example, a
- bug fix.
-
-- Make commits against the master branch. All development happens on
- the master branch. Releases are branched out from master in git.
-
-- Add or update documentation in the commit, as appropriate.
-
-- Write or update tests in the commit, as appropriate.
-
-- Individual commits should consist of atomic changes. A single
- commit should neither be in a partial state, nor should it contain
- multiple unrelated changes that could be split into separate
- commits.
-
-- The software should be reproducible. See
- <https://reproducible-builds.org> for more information.
-
-- When adding stuff that you did not directly make yourself it's
- important to preserve all copyright and license notices, to avoid
- putting this project at legal risk. Also, just because something
- you found somewhere doesn't have copyright or license information
- doesn't mean it's OK. Thanks to things like the Berne Convention
- things are copyrighted as "All Rights Reserved" by default, so if
- it's missing copyright and licensing information it's safest to
- assume it can't be used. When making the commit it is a good idea
- to set the name, email, and date to match who made it and when,
- although this part is not required.
-
-- What is required is to include enough information in the body of
- the commit message to identify who made it, where it came from,
- and why you believe it has an acceptable license. If there's a URL
- to refer to, include that in the commit body too and submit that
- URL to the Internet Archive's Wayback Machine for preservation:
- <https://archive.org/web/>. This helps to document who made what
- and where it came from, which is useful for future historians.
-
-- Ensure that each nontrivial file has copyright and licensing
- information inside of it, adding this if it is not present. This
- helps to ensure that information is retained when a file is
- separated from the version control system (i.e., in release
- tarballs.)
-
-Git Commit Messages
-===================
-
-- Limit the subject to 50 characters.
-- Use proper capitalization and imperative mood in the subject.
-- Don't put a period at the end of the subject.
-- Small changes, like fixing a typo, can get by with only a subject.
- Larger changes should include a body too.
-- Use a blank line to separate the subject and body.
-- Use the body to explain the what and why of the change.
-- Wrap the body at 70 characters.
-
-Coding Style
-============
-
-We use the coding style from the GNU Coding Standards. GNU Indent can
-be used to style your code appropriately. A summary of the options
-corresponding to that style are:
-
- -l79 Set maximum line length for non-comment lines to 79.
- -bap Enter a blank lines after function bodies.
- -bbo Break long lines before boolean operators.
- -bl Put braces on line after if, etc.
- -bli2 Indent braces by 2 spaces.
- -bls Put braces on the line after struct declaration lines.
- -cp1 Put comments to the right of #else and #endif statements in column 1.
- -cs Put a space after a cast operator.
- -di2 Put variables in column 2.
- -hnl Prefer to break long lines at the position of newlines in the input.
- -i2 Set indentation level to 2 spaces.
- -ip5 Indent parameter types in old-style function definitions by n spaces.
- -lp Leave space between ‘#’ and preprocessor directive.
- -nbad Do not force blank lines after declarations.
- -nbc Do not force newlines after commas in declarations.
- -ncdb Do not put comment delimiters on blank lines.
- -nce Do not cuddle } and else.
- -ndj Comments after declarations are treated the same as comments after other statements.
- -nfc1 Do not format comments in the first column as normal.
- -nfca Do not format any comments.
- -nprs Do not put a space after every '(' and before every ')'.
- -nsc Do not put the ‘*’ character at the left of comments.
- -nsob Do not swallow optional blank lines.
- -pcs Insert a space between the name of the procedure being called and the ‘(’.
- -psl Put the type of a procedure on the line before its name.
- -saf Put a space after each for.
- -sai Put a space after each if.
- -saw Put a space after each while.
-
-How to style your code is not the only thing covered in the GNU Coding
-Standards. Please consult the Standards for complete details.
-
-Documentation Style
-===================
-
-Documentation should be written using Pandoc's extended version of
-Markdown: <http://pandoc.org/MANUAL.html#pandocs-markdown>
-
-Line length should be set to 70 characters. To ensure that all
-documentation is styled consistently, run your documentation through
-Pandoc once it is written and have it convert it to its own Markdown
-format. Include the options
-`-f markdown -t markdown --columns=70 --wrap=auto`.
-
-Aside from the differences in documentation format, the information in
-the GNU Coding Standards for documentation is still relevant and
-should also be followed.
-
-License
-=======
-
-Copyright (C) 2017 The Muddle Project Developers
-
-You can redistribute and/or modify this file under the terms of the
-GNU Affero General Public License as published by the Free Software
-Foundation, either version 3 of the License, or (at your option) any
-later version.
-
-This file is distributed in the hope that it will be useful, but
-WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-Affero General Public License for more details.
-
-You should have received a copy of the GNU Affero General Public
-License along with this file. If not, see
-<http://www.gnu.org/licenses/>.
projects / muddle-interpreter.git / commitdiff