Address linter warnings

Author: ksen0

README.md

@@ -26,7 +26,7 @@ function draw() {
 </td>
 <td>
 
-<img src="./contributor_docs/images/p5-readme-sketch.png" width="200" height="200" />
+<img src="./contributor_docs/images/p5-readme-sketch.png" width="200" height="200" alt="p5.js sketch of overlapping circles forming tube-like shapes in black outlines on a white background." />
 
 </td>
 </tr>

contributor_docs/ko/method.example.js

@@ -1,5 +1,5 @@
 /**
- * "이것은 메소드의 인라인 문서 템플릿입니다. 이 템플릿을 사용하려면 큰 따옴표 
+ * "이것은 메소드의 인라인 문서 템플릿입니다. 이 템플릿을 사용하려면 큰 따옴표
  * 사이의 모든 텍스트를 제거하십시오.  메소드에 대한 일부 설명은 여기에 들어갑니다.
  * 간단한 단어로 함수가 하는 일과 그에 대한 좋은/나쁜 사용 예를 설명하십시오.
  * 만약 비정상적인 케이스나 경고가 있다면 여기에서 설명해 주세요."
@@ -31,7 +31,7 @@
  * "두 번째 예시를 명확히 설명하는 줄입니다"
  */
 
-// "메소드에 둘 이상의 특징이 있으면, 각 특징은 다음과 같은 파라미터 설명과 함께 
+// "메소드에 둘 이상의 특징이 있으면, 각 특징은 다음과 같은 파라미터 설명과 함께
 // 자체 블록에 문서화할 수 있습니다."
 /**
  * @method "메소드명"
@@ -46,11 +46,11 @@ p5.prototype.methodName = function() {
 
 // 이 부분은 템플릿을 채운 예시입니다.
 /**
- *  <a href="#/p5/background">background()</a> 함수는 p5.js 캔버스의 배경 색상을 
+ *  <a href="#/p5/background">background()</a> 함수는 p5.js 캔버스의 배경 색상을
  * 설정합니다. 이 함수는 일반적으로 draw()에서 각 프레임의 시작 부분에 디스플레이 
- * 윈도우를 지우는 데 사용되지만, 애니메이션의 첫 번째 프레임에 배경색을 설정하거나 
+ * 윈도우를 지우는 데 사용되지만, 애니메이션의 첫 번째 프레임에 배경색을 설정하거나
  * 배경을 한 번만 설정해야 할 경우 setup() 내에서 사용할 수 있습니다.
- * 
+ *
  * 배경색 기본 설정은 투명입니다.
  *
  * @method background
@@ -81,7 +81,7 @@ p5.prototype.methodName = function() {
 /**
  * @method background
  * @param {String} 문자열 형태의 색상 설정에 사용할 수 있는 형식:
-                   정수, rgb(), rgba(), rgb() 비율, rgba() 비율, 
+                   정수, rgb(), rgba(), rgb() 비율, rgba() 비율,
                    3자리 16진법, 6자리 16진법,
  * @param {Number} [a]
  * @chainable

contributor_docs/project_wrapups/akshaypadte_gsoc_2020.md

@@ -19,14 +19,14 @@ I had been a p5 user for more than a year and had come to love it and rely on it
 #### Part 1: Addressing known problems with the FES
 
 I kicked off the summer by addressing the issue of speed and size. The FES has a component called `validateParameters()`, responsible for checking if the arguments passed by the user are correct. It does this by matching the arguments against a file auto-generated from the inline docs. Earlier, this file was imported directly into the main library for the FES to use, but it also has a lot of information that is not needed by the FES which increases size unnecessarily. Pre-processing this file to keep only what was needed helped reduce the size of the final built p5.js library by around 25%.
-![](https://akshay-fes-gsoc.surge.sh/image1.png)
+![Graphical representation of bundle size reduced from 4.7 to 3.6 MB](https://akshay-fes-gsoc.surge.sh/image1.png)
 
 Another issue was speed. validateParameters does a lot extra work before the actual function is executed. Sometimes, as seen in [this](https://github.com/processing/p5.js-website/tree/main/src/assets/learn/performance/code/friendly-error-system/) performance test, it would slow down a function by up to 10 times. My initial assumption to speed it up did not work so I played around in chrome dev tools to figure out what was actually happening. I learnt that most of the time was spent just trying to figure out the nearest matching overload intended by the user, and that this entire process happened over and over again if the function was called multiple times with the same arguments. I addressed this with a trie like data structure <sup>[[1]](https://github.com/processing/p5.js/blob/8226395d40a9df0113b13e42c983ae578b3856fa/src/core/error_helpers.js#L300)</sup>, where each node represents an argument. Thus if a function is called again with the same sequence of arguments, we don't need to run the entirety of validateParameters. This not only improved the speed but also prevented the FES from flooding the console on repetitive calls of the same function.
 
 There was another issue which caused validateParameters to ignore the last undefined argument passed to function. This sometimes used to cause confusing and inaccurate messages. Fixing this was pretty easy and only involved one line of change.
 
 Moving on. There was an issue that if one p5 function called another p5 function, validateParameters would run both times. For example, the function saveJSON() needs to call saveStrings() to do part of its work. It forwards the arguments it receives to saveStrings(). This meant that if arguments were wrong when calling saveJSON(), we used to get two messages: one for saveJSON() and one for saveStrings(). But the user never called the latter in their code! This could lead to confusion.
-![](https://akshay-fes-gsoc.surge.sh/image2.png)
+![Illustration of two FES messages, only one of which should be shown.](https://akshay-fes-gsoc.surge.sh/image2.png)
 To fix this, one can take a look at the stack trace. We need to answer "was the most recent p5 function invoked from another p5 function?" If so, we don't need to display a message even if the arguments are wrong. I used another library [stacktrace.js](https://www.stacktracejs.com/), to help with this. Analyzing stack traces was extensively employed later-on in the project as well. We'll come back to it later.
 
 As a next step, internationationalization support was added for validateParameters messages and the language of some of the messages was simplified <sup>[[2]](https://github.com/processing/p5.js/pull/4629)</sup>. There were a couple of other small problems that were also fixed in this phase. You can see them in the full list of pull requests.