Skip to content

minor edits #10

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Megamega53 wants to merge 1 commit into
base: gh-pages
Choose a base branch
from
Open

minor edits #10

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions _posts/2020-03-29-week09.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,11 +19,11 @@ By next week, I hope to achieve the following:

## Wikipedia Contributions

I made my first contributions to Wikipedia this week. I updated the enrollment statistics for my alma mater, Fordham University. I discovered that this Wikipedia page is considered a [*good article*](https://en.wikipedia.org/wiki/Wikipedia:Good_articles), which is a type of article that meets certain criteria on Wikipedia. I think reviewing this type of page was a good place to start because it gave me an idea of what a well-written Wiki page looks like. After exploring several pages, I have come to realize that Wikipedia contains a plethora of information. Once I finished reading the contributing guide and primer for newcomers, I felt overhwhelmed by the amount of material. Although the primer provided useful knowledge for making contributions, I was still hesitant to make an edit. I found it difficult to read the primer because it is not well-organized. I expect a beginner-friendly guideline/tutorial to be clear and concise. The primer lays out all of the necessary information, but not in a structured way.
I made my first contributions to Wikipedia this week. I updated the enrollment statistics for my alma mater, Fordham University. I discovered that this Wikipedia page is considered a [*good article*](https://en.wikipedia.org/wiki/Wikipedia:Good_articles), which is a type of article that meets certain criteria on Wikipedia. I think reviewing this type of page was a good place to start, because it gave me an idea of what a well-written Wiki page looks like. After exploring several pages, I have come to realize that Wikipedia contains a plethora of information. Once I finished reading the contributing guide and primer for newcomers, I felt overhwhelmed by the amount of material. Although the primer provided useful knowledge for making contributions, I was still hesitant to make an edit. I found it difficult to read the primer, because it is not well-organized. I expect a beginner-friendly guideline/tutorial to be clear and concise. The primer lays out all of the necessary information, but not in a structured way.

I also updated the [Sephora Wiki page](https://en.wikipedia.org/wiki/Sephora). For this edit, I spent a significant amount of time researching the company. This page has some relevant and accurate information, but I would like to get it to reach the status of a good article.


## Why to Report Bugs

This blog post shed light on an issue that I was not aware of. I did not think users and developers would not be inclined to report bugs on an open source project. I just assumed that an open source community would not have this issue. I agree with another user's comment that describes this scenario as "the *bystander effect* applied to software". However, I also do not think you should rely on other people to find bugs in your project and point them out to you. I think this issue relates to an article I reviewed in a previous post. Except in this case, the project owner should not expect the users and fellow contributors to fix bugs on their behalf. At the end of the day, the project owner should encourage users to provide feedback and/or make contributions because the efforts of other contributors are voluntary.
This blog post shed light on an issue that I was not aware of. I did not think users and developers would not be inclined to report bugs on an open source project. I just assumed that an open source community would not have this issue. I agree with another user's comment that describes the scenario as "the *bystander effect* applied to software". However, I also do not think you should rely on other people to find bugs in your project and point them out to you. I think this issue relates to an article I reviewed in a previous post. Except in this case, the project owner should not expect the users and fellow contributors to fix bugs on their behalf. At the end of the day, the project owner should encourage users to provide feedback and/or make contributions, because the efforts of other contributors are voluntary.