Bug/Issue Fixes
Introduction
In the Bug Gardening Activity you became more familiar with your product and project by investigating bugs/issues that appeared in the issue tracker. In this activity you will attempt to fix bugs or address issues that appears in your project’s issue tracker.
Assignment
In this activity you will:
- Identify bug(s)/issue(s) to work on.
- Document your efforts in working on the bugs/issues in three ways:
- On a “Bugs/Issues Addressed” page on your team’s “Project Deliverables” wiki page (described below)
- In real-time using Slack Live-logs (see A05-Tech Spikes Activity).
- Weekly using 5-15 reports (described below).
- Give a team presentation of your work.
Additional details on all of these elements are given below.
Identifying Bugs/Issues
Most larger well-organized H/FOSS projects will have a collection of bugs/issues that have been tagged as “good first issue”, “beginner”, “introductory”, “easy”, etc. The developers have identified these as issues that have, in their opinion, a reasonably low barrier to entry and make good places to start. If your project does not have such a list you should search the issue tracker and find a bug that is well specified and seems approachable. If there is an appropriate communication channel for your project, you might also consider asking the community if they have any suggestions for bugs or issues that might be good for a newcomer to the project.
Many communites use specific proceedures for assigning bugs/issues to individuals. Other communities do not assign bugs/issues at all. Be sure to identify how your community handles (or does not) the assignment of issues and follow their proceedures. In particular, once you identify a bug/issue to work on, be sure to inform the community via the appropriate mechanism (if there is one) that you are working on it. If you ultimately fix the bug, or abandon work on it, again be sure to also inform the community via the appropriate mechanisms.
Documenting Your Efforts
You will document your efforts and results for this activity in three ways. Each team will collaboratively maintain a Bugs/Issues Wiki page that provides an overview of the work done by the entire team. You will continue to Live-log your indivial and sub-team work sessions in Slack to provide real-time information about when you have worked and the details of what you have done. Finally, you will write weekly 5-15 reports that summarise what you have accomplished, set goals for future work and reflect on your effectiveness and ways you can improve.
The Bugs/Isssues Addressed Wiki Page
- Create a link to a new wiki page named “Bugs/Issues Addressed” on your team’s “Project Deliverables” page.
- Give some header information on the new Wiki page that identifies your team and this activity.
- Create a table on the new Wiki page simialr to the one shown below:
Bug ID | Team Members | Description | Confirmed | Actions |
---|---|---|---|---|
The identifier for the bug as an active link into the issue tracker | Initials of team member(s) working on the issue | A short description of the bug | Yes/No/Unknown - does the bug exist in the current development version | Chronological list of each action taken on the bug with dates and active links whenever possible. |
7890 | GB/XY | Withdraw field allows zero amount. | No. | 11/1/22 - Appears to have already been fixed - Commented on the ticket suggesting it be closed. |
AB392c | GB/XY | Program crashes on dates before 1970. | Yes | 11/2/22 - Claimed in issue tracker 11/5/22 - Released in issue tracker - Appears to be too complex for our current level of familiarity. |
X5432b | JP/PQ | UI unresponsive when sorting data. | Yes | 11/5/22 - Assigned to self in issue tracker 11/6/22 - Proposed using Quicksort as a fix 11/9/22 - Made pull request 11/11/22 - Received request for changes on PR 11/13/22 - Pushed changes to PR 11/15/22 - Pull request merged! |
The table should:
- Document every bug/issue that your team attempts to work on, regardless of the final outcome.
- Include a list item for each significant event that occurs when working on the bug/issue. Significant events would be things such as:
- Starting work on the issue or claiming the issue.
- Any communications with the community on the issue tracker or otherwise. These should include live direct links to the communication whenever possible.
- Completion of work on the bug/issue, regardless of the final outcome.
Slack Live-Logs
As with your work on the A05-Tech Spikes Activity you are expected to document your efforst in real-time using Slack Live-logs as you work. You should make Live-log entries during every work session. These should document what you are doing, things you have tried, communications you have had with your project community (paste links), and resources you have used. Good live logs will reflect an effective, sustained effort of approximately 10 hours per week spread across multiple working sessions.
5-15 Reports
Approximately every week week you will produce a 5-15 report, either as a team or individually. A five-fifteen report is a short weekly templated report that is designed to enhance communication, reflection, prioritization, goal setting and time management without being time consuming. The name five-fifteen reflects that the report should take no more than five minutes to read and no more than fifteen minutes to write.
A key quality of good 5-15s is that each successive 5-15 clearly relates back to the prior 5-15s to document progress and identify persistent issues. Reading your 5-15s should make it make clear how:
- things that were planned turned into actions and eventually accomplishments.
- thoughts on ways to improve individual or team performance were enacted.
- how challenges/roadblocks were addressed and eventually overcome.
- etc.
Team 5-15
- Create a link to a new wiki page named “Team 5-15s” on your team’s “Project Deliverables” page.
- Give some header information on the new Wiki page that identifies your team and indicates that the page contains your 5-15s.
- Each Team 5-15 must have the headings given below and each must be followed by a few sentences or an annotated list providing the relevant information.
- Period Ending: (mm/dd/yyyy)
- Accomplishments:
- List and briefly describe the team’s accomplishments since the prior 5-15. Credit should be given to individuals when they have been instrumental in an accomplishment. You should explicitly connect back to goals that were set and challenges that were identified in prior 5-15’s.
- Team Function:
- Breifly describe how the team is functioning, any challenges it is facting and how the team function might be improved. You should explicitly connect back to challenges and ideas for improvement that were identified in prior 5-15’s.
- Blockers:
- Briefly describe any technical challenges/roadblocks is the team currently facing.
- Action Plan:
- Identify the items that the team will work on between now and the next 5-15 report. These might include new tasks, things ongoing from prior 5-15s and efforts to address the blockers that have been identified. Specific actions should be proposed and responsibility for them assigned to individuals or sub-teams.
Individual 5-15
- Create a link to a new wiki page named “Individual 5-15s” for yourself on the “Useful Information about Class Members” page (i.e. Where your blog and github are linked).
- Give some header information on the new Wiki page that identifies you and indicates that the page contains your 5-15s.
- Each Individual 5-15 must have the headings given below and each must be followed by a few sentences or an annotated list providing the relevant information.
- Period Ending: (mm/dd/yyyy)
- Contributions:
- Briefly describe what you did individually or collaboratively to contribute to your team’s accomplishments since you last individual 5-15. The items you discuss should clearly connect to your team’s accomplishements as documented in your Team 5-15s.
- Growth:
- Briefly describe what you have leared and the ways in which you have improved the way your work, collaborate, support your team, etc… since your last 5-15. The things that you discuss should generally connect to the goals that you set in your prior 5-15s.
- Goals:
- Briefly describe what you plan to do, learn, practice, change between now and your next 5-15 to improve your work, knowldge collaboration, teamwork, etc. Give specific actions that you will take to acomplish your goals.
Presentation
Each team will give a presentation of your work on the project. Your presentation should:
- Introduce your project assuming that the audience is not familiar with it. This should include:
- The mission of the project, what the product does, where it has been used, by whom and for what purposes.
- Describe / illustrate / demonstrate the bug(s) or issue(s) being addressed.
- Explain / illustrate / demonstrate what has been accomplished, how it has been done and why it was done that way. This should include:
- Relevant communications with the community
- Code/test implementations
- Demonstrations
Prepare this presentation for an audience of your peers (advanced undergraduate computer science majors). You may assume that they know a good bit about computer science and free and open source software. However, you should not assume that they know anything about the specific project your team is working on or the specific technologies that it uses. When discussing topics that are outside of the audience’s assumed knowledge, context and background sufficient for the audience to follow the presentation should be provided.
Grading
The Project Work assignment will be assessed using the rubric below.
Click rubric to enlarge image.
All textual materials used in this course are licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License
All executable code used in this course is licensed under the GNU General Public License Version 3 or later