From: Jason Self Date: Thu, 8 Feb 2018 22:56:28 +0000 (-0800) Subject: Remove contributing guide X-Git-Url: https://jxself.org/git/?a=commitdiff_plain;h=dddb84a711f2ae47f70b1e1bd1b51fa9b8565063;p=muddle-interpreter.git Remove contributing guide This is now on the website and no longer needs to live inside the interpreter repository. Signed-off-by: Jason Self --- diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md deleted file mode 100644 index a74571f..0000000 --- a/CONTRIBUTING.md +++ /dev/null @@ -1,178 +0,0 @@ -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: . 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 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 - 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: - . 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: - -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 -.