From 1c8dae7d6161c4238928c517b05fdb599366ef11 Mon Sep 17 00:00:00 2001
From: Jonathan Wilkes <jon.w.wilkes@gmail.com>
Date: Sun, 4 Mar 2018 18:06:18 -0500
Subject: [PATCH] improve contributor guide to accommodate newcomers with easy
bugfixes
---
README.md | 40 ++++++++++++++++++++++++----------------
1 file changed, 24 insertions(+), 16 deletions(-)
diff --git a/README.md b/README.md
index 4a114c292..7ba344b90 100644
--- a/README.md
+++ b/README.md
@@ -259,22 +259,30 @@ Contributing is easy:
1. Join the development list:
http://disis.music.vt.edu/cgi-bin/mailman/listinfo/l2ork-dev
-2. Tell us what you'd like to work on. There are lots of possibilities. For
- example, there are _lots_ of externals and even core features that are
- poorly documented.
-3. _No prototypes, please_. Purr Data's biggest strength is that users can
- turn an idea into working code very quickly. But a prototyping language that
- is itself a prototype isn't very useful. That means Purr Data's core code
- and libraries must be stable, consistent, well-documented, and easy to use.
-4. Develop incrementally. Small, solid improvements to the software are
- preferable to large, disruptive ones.
-5. Make sure you aren't duplicating existing functionality, especially core
- functionality. For backwards compatibility Purr Data ships many legacy
- libraries which unfortunately duplicate the same functionality. This makes
- it harder to learn how to use Pd, and makes it burdensome to read patches
- and keep track of all the disparate implementations.
-6. Send us a merge request and we'll test it. If it's well-documented and
- there aren't any bugs we'll add it to the software.
+2. Fork Purr Data using the gitlab UI and then try to build it from source
+ for your own platform using the [Build Guide](#build-guide) above.
+ If you run into problems ask on the development list for help.
+3. Once you have successfully built Purr Data, install it and make sure it
+ runs correctly.
+4. Start making changes to the code with brief, clear commit messages. If you
+ want some practice you can try fixing one of the bugs on the issue tracker
+ labeled
+ ["good-first-bug"](https://git.purrdata.net/jwilkes/purr-data/issues?label_name%5B%5D=good-first-bug)
+5. One you are done fixing the bug or adding your feature, make a merge request
+ in the Gitlab UI so we can merge the fix for the next release.
+
+A few guidelines:
+* _No prototypes, please_. Purr Data's biggest strength is that users can
+ turn an idea into working code very quickly. But a prototyping language that
+ is itself a prototype isn't very useful. That means Purr Data's core code
+ and libraries must be stable, consistent, well-documented, and easy to use.
+* Develop incrementally. Small, solid improvements to the software are
+ preferable to large, disruptive ones.
+* Make sure you aren't duplicating existing functionality, especially core
+ functionality. For backwards compatibility Purr Data ships many legacy
+ libraries which unfortunately duplicate the same functionality. This makes
+ it harder to learn how to use Pd, and makes it burdensome to read patches
+ and keep track of all the disparate implementations.
Here are some of the current tasks:
--
GitLab