Staying Ahead of the Kids
As part of my Open Source course at Seneca College, I and my classmates were assigned an ongoing project to contribute to a mixture of repositories. The twist being that some of these repos would be ones maintained by classmates in the pursuit of developing interesting projects that we came up with in class.
One of my classmates had two repositories, that other students seemed to like, and since I wanted to try my hand at trying to maintain a repo, I volunteered to help in that capacity. The idea for this repository was to create a speech recognition extension for Visual Studio Code that would transcribe certain voice commands into html code. For example if you were to say "div tag", to your computer's microphone, it would print "<div " to the page, allowing out to add some attributes, and later close the tag through speech commands as well. As I mentioned, this was the idea of one of my classmates, and the repository can be found here.
So far, I have found being the role of a maintainer to be a bit of a challenge, because it forced me to shift form the mentality of a being just a coder. The difference being that if you're working through your own problems, your personal experience with the issues can feed back into how you think they should be solved. In the end, you know how the entire process is supposed to work, and you can then share this with others.
This approach is horribly inefficient when trying to maintain a repository. An old quote from the Simpsons comes to mind where Marge says she can teach piano lessons as long as she stays one lesson ahead of the kid she's teaching. The fallacy here being that I thought I had to be ahead of people who would work on issues. In order to post an issue, and adequately review the pull request, I would at least have to go through the process myself.
This approach is not really sustainable since it leads to the duplication of effort. The maintainer does something as well as the person offering their help. Knowing exactly what is going on may be necessary for the initial issues in a repo since you need to know how the environment works, but the challenge now will be to figure out how to provide information on potential areas of study so that people can go off and make something. Duplicating the effort is impractical, especially since someone may find an alternate (and possibly better) way of doing things. A pragmatic and concrete examination of issues before people take them on is not useful here. Instead, striking the balance between letting someone take the initiative to figure out how to move the project forward, and knowing a decent amount about a task to make recommendations that are specific enough that people can act on.
As an example, I've gotten a decent balance from this issue in this repository. I really need to continue on with this issue--especially since one of my classmates has a project that is also written in Rust.
One of my classmates had two repositories, that other students seemed to like, and since I wanted to try my hand at trying to maintain a repo, I volunteered to help in that capacity. The idea for this repository was to create a speech recognition extension for Visual Studio Code that would transcribe certain voice commands into html code. For example if you were to say "div tag", to your computer's microphone, it would print "<div " to the page, allowing out to add some attributes, and later close the tag through speech commands as well. As I mentioned, this was the idea of one of my classmates, and the repository can be found here.
So far, I have found being the role of a maintainer to be a bit of a challenge, because it forced me to shift form the mentality of a being just a coder. The difference being that if you're working through your own problems, your personal experience with the issues can feed back into how you think they should be solved. In the end, you know how the entire process is supposed to work, and you can then share this with others.
 |
| I can help maintain a repo, right? |
This approach is horribly inefficient when trying to maintain a repository. An old quote from the Simpsons comes to mind where Marge says she can teach piano lessons as long as she stays one lesson ahead of the kid she's teaching. The fallacy here being that I thought I had to be ahead of people who would work on issues. In order to post an issue, and adequately review the pull request, I would at least have to go through the process myself.
This approach is not really sustainable since it leads to the duplication of effort. The maintainer does something as well as the person offering their help. Knowing exactly what is going on may be necessary for the initial issues in a repo since you need to know how the environment works, but the challenge now will be to figure out how to provide information on potential areas of study so that people can go off and make something. Duplicating the effort is impractical, especially since someone may find an alternate (and possibly better) way of doing things. A pragmatic and concrete examination of issues before people take them on is not useful here. Instead, striking the balance between letting someone take the initiative to figure out how to move the project forward, and knowing a decent amount about a task to make recommendations that are specific enough that people can act on.
As an example, I've gotten a decent balance from this issue in this repository. I really need to continue on with this issue--especially since one of my classmates has a project that is also written in Rust.
Comments
Post a Comment