class: center, middle # CSCI-UA 480.10: OSSD ## Open Source Software Development <br> ## Contributions .author[ Instructor: Joanna Klukowska <br> ] .license[ Unless noted otherwise all content is released under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). ] --- ## Course Related Contributions - course website - report an issue (this by itself is a contribution) - make sure to check if the issue was already reported (if it was, you may add a comment to it or try to fix it) - comment on an issue (as long as it adds value to the issue report, it is a contribution) - fix the reported issue and make a pull request - check the status of your pull request in case the mantainer has asked follow-up questions or made comments If you report an issue, leave it for someone else to fix it. The goal of this is to practice the process. - other students' blogs - report issues, fix the reported issues and make pull requests (check the status of your pull request in case the mantainer has asked follow-up questions or made comments) - formatting related - broken links, missing images, ... - grammar/spelling related (do not be picky) - do NOT rewrite other people's blogs --- ## Non-coding contributions - Wikipedia - you should have an account by now - Wikipedia has an article titled [Contributing to Wikipedia](https://en.wikipedia.org/wiki/Wikipedia:Contributing_to_Wikipedia) - this is a good place for you to start - OpenStreetMap - you should have an account by now - to contribute, you may want to start on the [OpenStreetMap Main Wiki page](https://wiki.openstreetmap.org/wiki/Main_Page) - there is a [Beginners' Guide](https://wiki.openstreetmap.org/wiki/Beginners%27_guide) there that will help you in making the first contribution - others --- ## Contributions to FOSS projects .left-column2[ - programming - user interface design - web design - accessibility design - graphic design - manual/example writing - manual/example editing/updating - documentation writing - documentation editing/updating - translations ] .right-column2[ - code testing - accessibility testing - user interface testing - bug triage - project management - community mangement - event organization and coordination - public relations and outreach - marketing ] --- ## Logging Contributions Make sure that all your contributions are logged on your blog. - date - link to the contribution - brief description of what you did --- ## Course Website - Reporting Issues - As you are exploring the course website, take a note of any problems, inconsistencies, broken links, misformatting, etc. - Once you discover a problem, go the the course website repository and look through the existing issues. - If the issue that you found has not been reported yet, report it. Provide a detailed description of the problem (when it occurs, why you think it is a problem), state which browser and operating system (name and version) you are using. - If the issue has been reported, you can comment on it. If nobody verified it before, you can add a comment stating that you have also encountered the issue. If other people already verified it, but you have additional details to add, you can do that as well. You can also suggest a solution, if you think that you know how to solve it. - If you find reported issues that are not really issues, you can contribute that to the discussion. -- __You should pay close attention to the issues that you reported and commented on.__ Other people may ask follow-up questions and suggest modifications to the issue. Eventually, someone may provide a fix to an issue and you should be able to verify quickly that their fix actually works and that it fixes the issue. You should respond to all such comments and requests in a timely manner (i.e., a couple of days, not weeks). -- The general goal is to report at least one issue. If you are comfortable with issue creation, you do not need to report any. If you want practice on it, you can report more than one. --- ## Course Website - Claiming Issues If you want to fix an issue, you should first claim it. Add a comment to one of the issues that you would like to fix. The comment should basically state "I would like to claim this issue." or "I'd like to work on this.", or ... -- Make sure that you wait for the response before you start working on the issue! -- __Restrictions__<br> you will not be assigned to fix an issue that you reported yourself. For that reason, there is no point in claiming an issue that you reported. -- It may be a good idea to claim issues that have not been claimed before since we will use "first come first serve" rule in assigning the issues. -- You should claim, and then fix, at least one issue. But if you know you need practice with working with git and with making pull requests, etc, you can (and should) work with more than one issue. --- ## Course Website - Fixing Issues You should not work on an issue that you were not assigned. Pull request from contributors who did not successfully claim the issue will be rejected. -- Attempt to fix the issue and submit a pull request. You should make a fork of the existing code and make and test all the changes that you are proposing in that fork repository. If you enable github pages for that repository, then you can verify that the issue that was reported is actually fixed and that your fix did not break any other parts of the website. Make sure that you carefully read the report of the issue and all/any follow-up discussion. Your fix should implement exactly what was agreed on (do not include fixes to other issues, or fixes to other unreported problems). -- Issue a pull request. In the pull request you should ask the original poster of the issue and (optionally) the people who commented on the issue to verify that the fix is acceptable to them. Provide a link to your fork that stores a functional website with your changes. <br> If there are merge conflicts when you issue a pull request (or if any merge conflicts arise after you issued the pull request, but before it was merged), you HAVE to resolve them before the pull request can be accepted. - use @USERNAME to mention particular users (people who reported an issue) - use "Resolves #NUM" where the NUM is the issue number, so that when the pull request is merged, the issue is automatically marked as resolved -- Make sure that you pay close attention to the pull request until it is rejected or merged. The maintainers and/or original posters may ask you to make changes and you should respond to such comments and requests in a timely manner. --- ## Course Website - Fixing Issues As people submit pull requests in order to fix the issues, the original posters (and anybody else) should be verifying that the fix is really relevant to the original issue and that it fixes it according to the discussion for the issue. The author of the pull request should provide the location of a fork for the website so that people can easily verify it. As changes are incorporated into the website, there may be new issues coming up. If you spot a new problem or previously unreported problem, feel free to report it as a new issue or comment on the previously reported issue. If an issue is closed and you discover that the problem still exists, you should suggest that it is reopened. If an accepted fix introduces a new problem, report it as a new issue but mention all other issues and pull request that might be related to this new problem. --- ## Course Website - Code of Conduct __Always remember that you are working/collaborating with other people. BE COURTEOUS!!!__