Minor fixes to inaccurate contributor docs

Author: limzykenneth

contributor_docs/inline_documentation.md

@@ -4,7 +4,7 @@ By adding inline documentation in the p5.js source code, a reference can be auto
 
 See below for the basics, more specifics about yuidoc style [here](http://yui.github.io/yuidoc/syntax/index.html). __Please limit line length to 80 columns, starting new lines when it runs over.__
 
-__[List of examples needed](https://github.com/processing/p5.js/issues/1954) (you can also view the most up to date list by building the library with grunt and looking at the log messages)__
+__[List of examples needed](https://github.com/processing/p5.js/issues/2865) (you can also view the most up to date list by building the library with grunt and looking at the log messages)__
 
 ## Specify element type and description
 

contributor_docs/organization.md

@@ -1,17 +1,17 @@
 # Organizing Contributions
-
 Keeping the repository organized ensures that it is always clear which discussions and tasks are the most important. This helps everyone from maintainers to new contributors navigate the repository without getting overwhelmed. To help with this, we have a set of guidelines for how to organize issues, work, and pull requests.
 
 Helping with organization can be a great way to contribute. If a bug report is missing information such as example code, feel free to chime in and ask for the missing info. If an issue with an assignee has seen no activity for 60 days, it can be helpful to comment on the issue to check in with the assignee to see if they still want to work on the issue. Whenever you are helping with organizational tasks, make sure to be kind and always keep the community guidelines in mind.
 
 # Guidelines for Organization
 
 ## Issues
+- **All issues should use the relevant issue template**
 - **All bug reports should include sample code**
   - This can be in the form of code posted in the body of the issue, or it can be a link to an online example of the code preferably in [the online editor](https://editor.p5js.org)
 - **All issues should have at least 2 labels**
   - This makes it much easier to navigate the issues.
-  - Try adding a label for the area (webgl, core, image, etc)
+  - Depending on issue template used, labels for area will be automatically set in many cases. You can add additional labels as required.
 - **Issue assignment is first-come, first-serve**
   - If a bug has been reproduced, or a feature request/enhancement has been agreed upon by the community, it becomes available for assignment. When this happens the first contributor to request assignment by saying something like "I'd like to work on this issue!" will be assigned.
   - Do not request to be assigned to an issue if it is unclear whether the bug is reproducible or the feature request/enhancement has been agreed upon.
@@ -24,10 +24,9 @@ Helping with organization can be a great way to contribute. If a bug report is m
 
 
 # Guidelines for Decision-Making
-
 p5 aspires to make its decision-making process as transparent and horizontal as possible. To do this, p5 uses an informal consensus-seeking model for decision-making. This means that we prefer to reach community consensus on any and all decisions. If this fails, then a vote will take place instead.
 
-**Stewards** have the ability to veto proposals. This can happen when a proposal doesn't align with the mission/community guidelines, or  when a proposal presents a significant maintenance or implementation challenge that the project is not able to tackle at that time.
+**Stewards** have the ability to veto proposals. This can happen when a proposal doesn't align with the mission/community guidelines, or when a proposal presents a significant maintenance or implementation challenge that the project is not able to tackle at that time.
 
 To propose a change, open an issue. If it is a large change or a change that necessitates significant design consideration, add a 'discussion' label to the issue. Interested community members will chime in with their thoughts. After a significant period has passed (30 days unless urgent), maintainers will try to discern whether there is significant interest and whether consensus has been reached about the best approach. At this point, maintainers will either request a vote, close the issue, or open up the issue for pull requests. Pull requests submitted before a discussion has concluded will be ignored.