In chapter 8 and 9 of Teaching Open Source, we read about documentation. Within Jupyter there are not a lot of comments within the code. This can be problematic, and forces us to wait on the replies of more experienced contributors when trying to understand a piece of code. This slows down our progress and the progress of other contributors when they have to take time to answer our questions. There is documentation in the project's Github page, especially when it comes to installation. Lack of documentation is a common occurrence in open source software. We experienced this problem last semester too when working with Tanaguru. There was very little in the way of installation, and much of what there was outdated. Lack of documentation is a common pitfall in open source projects and we should all work harder to contribute.
The exercise involved commenting and documenting on our code within the open source project. Our first issue involved correcting some accessibility problems.We commented on code we changed with explanations of the color values we changed to make some text and buttons more visible. The code that we edited and fixed now stands out somewhat in the source code due to the lack of comments made by other contributors.
Wednesday, April 25, 2018
Planning to Meet Charleston
Along with my group member Ethan Hendrix, I am planning to attend the SC Linux Users Group. The group is focused first and foremost on the Linux operating system. They also have discussions on other forms of open source software. I find this interesting due to my work with open source in the CIRDLES lab. I would like to learn more about Linux as well. Right now, I only have experience with Ubuntu running on a virtual machine. I would like to run Ubuntu primarily on my machine in the near future. The group holds meetings on the second Saturday of each month and the next meeting is March 10.
Tuesday, February 20, 2018
Reflections on my Progress
When we first developed our timeline, we were conservative in our estimate of how many issues we could tackle within Jupyter Notebook. We noticed that bugs in the project get fixed very quickly, so we were worried bugs we worked on would be finished by someone else. We are now ahead of schedule because of this. For our next task, we have decided to tackle adding a file upload activity indicator:
Right now, the user does not get any feedback when they are uploading a file. The user has no way of knowing the program is doing what its supposed to. Our task is to add this feedback. We have discussed a few different approaches to accomplish this. One approach is a loading bar. This would provide the most feedback to the user since they would get a visual of the progress the program is making. However, this would be difficult for us to implement due to the involvement of graphics and our lack of knowledge of the components that upload the files. We would have to find or create the graphics to create a loading bar. We would have to thoroughly understand the process the program goes through to upload files to be able to properly represent its progress visually. Because of these foreseen difficulties, this will not be our first approach. Instead will will start with a simple text box message that appears when the file starts uploading and disappears when its finished.
Tuesday, February 6, 2018
This bugs me
6.4 Find the oldest bug that’s still open in your chosen project. Write a blog entry describing the problem, with a theory about why the bug hasn’t been resolved yet. (Bonus points if you can actually resolve the bug.)
https://github.com/jupyter/notebook/issues/56
Jupyter Notebook's oldest open issue was first created on April 28, 2015. It involves creating keyboard shortcuts to simplify help requests involving some called "mimebundles." I do not have a full grasp on the issue since I have no idea what a mimebundle is. It appears that many contributors feel that returning information in a mimebundle would be better suited to program as a whole instead of returning information inline as it does now. Both new and experienced contributors have worked on this issue. It has been edited and updated several times over the years. It was last discussed just a few months ago in December of 2017.
6.5 Figure out how to create a new account on the bug tracker of your chosen project. You’ll need that account very soon.
Jupyter Notebook does not use a specific bug tracker. Instead, they are posted to Github as issues. Issues often do not last longer than a few days, so this system seems to suit the project. However, this can make it difficult to claim a bug since someone else might just fix it before you. We will need to act quickly to be able to contribute to the project. We can also communicate through Gitter and Slack to discuss the project and bugs with other contributors.
https://github.com/jupyter/notebook/issues/56
Jupyter Notebook's oldest open issue was first created on April 28, 2015. It involves creating keyboard shortcuts to simplify help requests involving some called "mimebundles." I do not have a full grasp on the issue since I have no idea what a mimebundle is. It appears that many contributors feel that returning information in a mimebundle would be better suited to program as a whole instead of returning information inline as it does now. Both new and experienced contributors have worked on this issue. It has been edited and updated several times over the years. It was last discussed just a few months ago in December of 2017.
6.5 Figure out how to create a new account on the bug tracker of your chosen project. You’ll need that account very soon.
Jupyter Notebook does not use a specific bug tracker. Instead, they are posted to Github as issues. Issues often do not last longer than a few days, so this system seems to suit the project. However, this can make it difficult to claim a bug since someone else might just fix it before you. We will need to act quickly to be able to contribute to the project. We can also communicate through Gitter and Slack to discuss the project and bugs with other contributors.
Tuesday, January 30, 2018
Reflections on Open Source in Today's World
Why isn't open source hot among computer science students?
This article strives to address misconceptions held by those who are new to the computer science field. The author surveyed 26 attendees of a hack-a-thon for high school and college aged programmers. Personally, I believe this is too small of a sample, but I found my self agreeing with the points she makes. First she points out that novice programmers would rather work on their own projects than contribute to an open source project. When I was a freshman and software, I had several small projects which were nothing more than toys. I could have learned a lot more my attempting to contribute to an open source project. The author also points out that many new programmers do not feel that their skills are up to snuff. Contributing to a an open source project is intimidating and it can be difficult to figure out what is the best way to contribute early on. However, I have noticed that many open source projects are welcoming and have easier tasks set aside for on-boarding new developers. The last point the author makes is that young programmers often believe proprietary software is simply better than open source software. This is not true and its easy to point to examples like Firefox to show what open source is capable of. I am relatively new to open source, but I hope to contribute to open source projects in some capacity for a long time to come.
Can anonymity and accountability coexist?
The author starts by pointing out how anonymous communicative has always existed outside of the internet such as whistle-blowing, voting, and crowd sourcing. These forms of communication can lead to a more open flow of ideas. This thought is continued in the authors first example of reddit (my favorite website) allowing the free flow of creative and imaginative ideas through anonymity. However, as a regular user of the site, I have seen how anonymity has allowed the flow of dangerous or malicious ideas that would never be shared outside a cloak of anonymity. The author points out that there often is a lack of accountability. The author believes there should be other forms of non-anonymous communication to go along side anonymous communication channels.
This article strives to address misconceptions held by those who are new to the computer science field. The author surveyed 26 attendees of a hack-a-thon for high school and college aged programmers. Personally, I believe this is too small of a sample, but I found my self agreeing with the points she makes. First she points out that novice programmers would rather work on their own projects than contribute to an open source project. When I was a freshman and software, I had several small projects which were nothing more than toys. I could have learned a lot more my attempting to contribute to an open source project. The author also points out that many new programmers do not feel that their skills are up to snuff. Contributing to a an open source project is intimidating and it can be difficult to figure out what is the best way to contribute early on. However, I have noticed that many open source projects are welcoming and have easier tasks set aside for on-boarding new developers. The last point the author makes is that young programmers often believe proprietary software is simply better than open source software. This is not true and its easy to point to examples like Firefox to show what open source is capable of. I am relatively new to open source, but I hope to contribute to open source projects in some capacity for a long time to come.
Can anonymity and accountability coexist?
The author starts by pointing out how anonymous communicative has always existed outside of the internet such as whistle-blowing, voting, and crowd sourcing. These forms of communication can lead to a more open flow of ideas. This thought is continued in the authors first example of reddit (my favorite website) allowing the free flow of creative and imaginative ideas through anonymity. However, as a regular user of the site, I have seen how anonymity has allowed the flow of dangerous or malicious ideas that would never be shared outside a cloak of anonymity. The author points out that there often is a lack of accountability. The author believes there should be other forms of non-anonymous communication to go along side anonymous communication channels.
Thursday, January 25, 2018
I'm Git'n it
Git vs Github
Git is a version control tool that is run from the command line or terminal. It allows multiple people to contribute to one project at the same time. It it is also helpful for retrieving past versions of a project if a developer is unhappy with recent changes to the project. Github is a collection of repositories where code is stored. It is where code is pushed to and pulled from when we use Git. Github has a social aspect in that most projects can be viewed by anyone. Many projects on Github are open source.
Previous Experience with Git
I have used both Git and Github for a few years now. I first learned it for my work in Dr. Bowring's CIRDLES lab. I remember there being a steep learning curve, and I often had difficulty keeping my branches up to date when others committed work. I got the hang of it with the help of my team members.
Git and Ubuntu
When I first began installing Git on my Ubuntu virtual machine, I expected there to be some sort of difficulty due to my past experiences. I can recall very few times when installing anything on Ubuntu didn't involve some sort of hiccup. I was almost surprised when installing git took only seconds and worked just as I expected it to.
Git is a version control tool that is run from the command line or terminal. It allows multiple people to contribute to one project at the same time. It it is also helpful for retrieving past versions of a project if a developer is unhappy with recent changes to the project. Github is a collection of repositories where code is stored. It is where code is pushed to and pulled from when we use Git. Github has a social aspect in that most projects can be viewed by anyone. Many projects on Github are open source.
Previous Experience with Git
I have used both Git and Github for a few years now. I first learned it for my work in Dr. Bowring's CIRDLES lab. I remember there being a steep learning curve, and I often had difficulty keeping my branches up to date when others committed work. I got the hang of it with the help of my team members.
Git and Ubuntu
When I first began installing Git on my Ubuntu virtual machine, I expected there to be some sort of difficulty due to my past experiences. I can recall very few times when installing anything on Ubuntu didn't involve some sort of hiccup. I was almost surprised when installing git took only seconds and worked just as I expected it to.
Tuesday, January 23, 2018
Joining the Project
After looking into our original three choices for our FOSS project to work on, we thought we would work on Yoda-Pa. However, we found that there was a very small number of issues to working, meaning our overall body of work for the rest of the semester could potentially be small. We looked at other projects and decided on Jupyter Notebook. Jupyter notebook is an open source notebook project with a thriving community and hundreds of well documented issues to work on. Some issues are even tagged specifically for newcomers to work on to get a feel for the project.
Joining the community was easy. I joined the community mailing list with my google account to receive updates on the project as a whole. I also joined the Jupyter gitter for chatting with others working on the project. There is also a stack overflow page for solving issues related to Jupyter. Overall, it appears the community is thriving and welcoming to newcomers.
Subscribe to:
Posts (Atom)