Assignment 2 (Group): Learning Infrastructure for a Large Project [100 MARKS]

Due date: 27th of August (Sunday) 2023, 11:59pm
Assignment Weighting: 15% of total grade
Starting the assignment: See the instructions
Submission: Submit your through Wattle TurnItIn - See further instructions below
Assignment 2 FAQ: See the FAQ for this assignment
Policies: For late policies, plagiarism policies, etc see the policies page

For this assignment, you will need to submit a single group report on Wattle. See further instructions below

Students can get full GitKraken for free if they register with their ANU email for the GitHub Education Student Developer Pack. Ask your tutor or post on EdStem if you have any difficulties.

You can also optionally choose to use draw.io to create diagrams for your project if you wish to do so. Ensure that exported images are of sufficient resolution (DPI) and are clearly labelled for marking. It is encouraged to embed any images in the markdown files themselves, see the markdown guide if you are unsure about how to do this. Images must also be of sufficient quality

The repository your group will be using for this assignment is listed here.

You can see your group allocation here.

You are not expected, nor is it required to download and build your assigned repository to complete this assignment. If you wish to do so, you can follow the instructions within their respective README/documentation. We will not be providing any technical support if you choose to install and build it yourself, the next assignments will be more hands on for those wanting to get more practical. If you do manage to get it working, does it meet your expectations after answering the questions in this assignment?

This assignment will require you to elaborate detailed explanations. All requirements for you to address are expressed as dot points you must achieve. However, when you are writing do not paraphrase the same sentence multiple times to add more words. Do not write “filler” statements. Write meaningful, relevant content.

Activity 1 [30 marks]#

Inspect the releases, the branches, the forks and the contributors to sketch which configuration management activities are being managed (skip problem tracking) and how they are handled.

You can use tools to complete this analysis. For example, tools like GitKraken (or similar) will plot the structure of branches for this (and you could see if bots committed). To peruse the labels on the issues and pull requests, see which branches are merged into what, determine which tools the developers are using, you can look at GitHub Actions (especially if you also examine GitHub Action’s official documentation). You can use other tools not mentioned here (because these are just examples); just be mindful of mentioning how each tool (by name, and ideally with a footnote+URL) helped you at each/specific stage of the analysis of the repository.

It will not be possible for your team to actually trace back the entire process and you will be left with “gaps” that do not have evidence, that have contradicting evidence, or even that could be translated into two or three options. Be sure to note them down, and for the corresponding subtasks explain why you cannot infer a particular process or step. Remember that the goal is not to obtain the most complete details of the DevOps process, but to be critical with your inferences, and ascertain only that for which you have evidence.

Task 1.1 [10/30 MARKS]#

Your explanation should include, but not be limited to the following:

Where the information was obtained
Which elements you triangulated to “infer” every piece of information (from the steps to the tools used)
Possible elements contradicting your inferences, and why you “discarded them” (basically, why this wasn’t enough to convince you that the process was different).
Associate each part of the process you identified to the DevOps phases (we discuss this a bit more in later lectures, but for this assignment you do not need much detail other than the general subject for each phase as described here or in many other tutorials).
Explain how branches are being used, and what’s the process to “branch out” and “merge” (the process for this may be different between “types” of branches, and if this is the case, you have to note it and explain it).
You are not required to analyse which are the libraries dependencies, but if there is a process to add/remove a library, then you have to include it.

Task 1.2 [10/30 MARKS]#

Write up your opinion as a group on their process. Include any relevant diagrams if you made any. This paragraph must reflect fluidly on the following questions.

Is there anything that could be done to be improved?
Did you learned anything new about watching this process?
Would this large-scale process be applicable as-is for a small-scale (say, 5-people team)?
Which DevOps principles (everyone is responsible for everything; everything that can be automated should be automated; measure first, change later) were you able to identify here? (provide the evidence of the “clues” that lead you to identify a principle).
Is traditional semantic versioning followed, if not why?
Are the number of changes for each version bump consistent (major and minor versions)?
Are issues handled in a way that is consistent throughout the repository?

Task 1.3 [10/30 MARKS]#

While you are looking through the history of the repo, an important skill is identifying and using design patterns in code. Split up the task of looking through the code in your assigned repository among your group members and analyse and identify at least several well justified occurrences per team member. Try to find at least half a dozen different design patterns in use, or consult with your tutor if you are struggling to find any.

Design patterns describe best practices for code quality and industry standards.

Examples of common design patterns are, and your analysis should not be limited to only these:

Creational patterns (Class and object creation)
Structural patterns (Class and object composition)
Behavioural patterns (Class and object communication)

Include screenshots and links to design patterns found, justifying why your chosen your examples, what the pattern name is, the type of the pattern. Also include a link to the file via GitHub for reference.

Additionally, while you are looking through your assigned repository, keep an eye out for any code smells (Large classes, unused/commented out code, irrelevant names, etc). If you find any code smells, include a link to the file, a screenshot, and an explaination as to why you believe it is a code smell. If you are able to, how would you fix the code smell if you were to open a PR with a change?

As per Cambridge Dictionary, infer means “to form an opinion or guess that something is true because of the information that you have”.

Activity 2 [30 MARKS]#

Problem tracking is a fundamental tool in software development, and in open-source software it allows users to report problems. For this item, you will have to analyse the issues of the repository.

Task 2.1 [10/30 MARKS]#

Find as many examples are there are members in your team (i.e 4 examples for a team of 4) of poorly explained issues (the problem has to be badly worded, not fully exemplified, lacking information, etc.). Share the examples here (with an URL to the issue, and a screenshot of it). Explain why you chose those examples.

Task 2.2 [10/30 MARKS]#

Find as many examples are there are members in your team (i.e 4 examples for a team of 4) examples of users not acting in the best interests of the project repository assigned to your group. Share the examples here (with an URL to the issue, and a screenshot of it), and explain how they did not act in the best interests of the project. Explain why you chose those examples.

Task 2.3 [10/30 MARKS]#

Find as many examples are there are members in your team (i.e 4 examples for a team of 4) examples of excellently presented issues, which contain all the information that you deem necessary for developers to address the issues. Share the examples here (with an URL to the issue, and a screenshot). Explain why you think they are good issues.

After, summarise in at least six dot points the key elements an excellent issue should contain. Take a look at the Week 2 slides on INVEST guidelines.

Activity 3 [30 MARKS]#

In this section you will be examining the code review practices of the project. To do this, you will need to inspect the pull requests (both open AND closed) to complete the tasks below.

Task 3.1 [10/30 MARKS]#

What are the most relevant causes for Pull Requests (PRs) to be closed without being merged? You do not need an ML classifier for this, don’t go overboard. Use the filters provided by github, and check the labels. Gather as many examples are there are members in your team (i.e 4 examples for a team of 4) of PRs that are not merged. Share the URLs of the PRs, and a screenshot of them. Discuss why they were not merged (remember to provide evidence supporting your inference).

Additionally, discuss whether this a problem that can be mitigated (e.g. with automated detection) or not.

If your group has been assigned https://github.com/google-research/bert and you are struggling to find anything for this task, please complete this task with the https://github.com/spring-projects/spring-boot repository instead. This will be fixed in future iterations of the course and will be taken into account for marking. If you are having difficulties with other Activities, let your tutor and Alex know ASAP.

Task 3.2. [10/30 MARKS]#

What is the general process of an accepted/merged PR? Take into account when bots are used (if they are used), how/when people are assigned to a PR, if PRs are linked to issues or related among them (one PR being mentioned in another PR, but not as duplicates). See if there are any coding practices shown as favourable in the project that tend to lead to an acceptance/review. Consider how the branches’ purpose affects the PRs.

Find as many examples are there are members in your team (i.e 4 examples for a team of 4) for all the points mentioned above, if applicable/relevant. If your group finds anything else of interest, it can also be included in your submission.

Task 3.3 [10/30 MARKS]#

Which inspection checks are generally being conducted? There are 6 kinds of fault classes shown in the slides for the inspection lecture in week 5 (on slides 13 and 14). Since your team has 4 to 5 team members, find a single example of a different fault class for as many classes as there are members in your team (i.e. for a team of 4, find a single example each for 4 different fault classes). For each of these examples you need to find a PR comment (it can be a sentence inside a comment), and discuss why these comments provide evidence for that particular fault class check. Remember to provide URL + screenshot of the comment.

Note for students: The following are research papers done regarding PRs acceptance/rejection on a number of projects. While reading them is not required nor enforced, their findings (Results and Discussions) will generally give you incredible insights on what to search for to complete points 3.1. and 3.2. ¹ ² ³ ⁴

Activity 4 [10 MARKS]#

Task 4.1 [10/10 MARKS]#

For this task you are required to answer:

What the license of the project is
What it allows and doesn’t allow
What the license of the project repository assigned to your group means for the project, what can and can’t it be used for?

Setup and Preliminary Instructions#

As a group, you read and understand all of the tasks and questions in this assignment before starting. It is advised to plan out and assign each group member a fair share of work.

You are required to work together as a team, if you encounter any problems you should let your tutor and Alex know as soon as possible.

Before starting the assignment or submitting your report, verify that all group members in your group appear correctly within the group allocation list and you are looking at the correct repository assigned to you listed here.

Submission Instructions#

You will be required to submit a single group report through Turnitin in PDF format on Wattle - Assignment 2 Submission. Report submission format.
- Your report should include a references/collaboration section if you used any external resources (i.e. web pages, document, books), or if you collaborated with members outside of your group.
You will also be required to submit a group and individual reflection via a Wattle Quiz. This is anonymous to your group members and should be used to honestly evaluate the performance and contribution of every group member. This group reflection will be taken into consideration when marking and individual marks may be adjusted accordingly as required. Your group size will also be taken into consideration.
Fill in the Statement of Originality quiz on Wattle confirming that any work you contributed was your own. Submitting this is required for marks to be awarded.

FAQ#

A FAQ for frequently asked questions about the assignment.

My group member(s) aren’t contributing/There are issues with my group#

Let your tutor and Alex know as soon as possible if any issues arise. The earlier the better. Remember, you also have the opportunity to honestly reflect and evaluate the performance and contribution of every group member.

Members will be scaled via this formula https://comp.anu.edu.au/courses/comp2120/scaling based on group feedback provided in the Wattle Quiz.

My group has more or fewer members than some other groups. This isn’t fair.#

Your group size will be taken into consideration when marking occurs.

Is there a total word count or page limit?#

No, however, do not paraphrase the same sentence multiple times to add more words. Do not write “filler” or unnecessary statements. Write meaningful, relevant content.

What kind of screenshots need to be included?#

A screenshot of the title and the original comment along with the URL for the issue. Make sure that any images you add to your report are of sufficient quality, and are easily readable for tutors when marking.

For example:

Pre-submit tests not being triggered. #109279 - URL: https://github.com/flutter/flutter/issues/109279

Note that images you insert into your report must be larger than the image shown here and of sufficient readable quality for marking. Try to be consistent with image formatting/sizing.

Some of the questions include content not yet covered#

You can access all past and upcoming (draft) slides on the course website in the interm.

Format of the report#

While there is no particular standard/format for the report. As long as we can clearly see what question you are answering and it is presented in a well structured, readable format we will be happy.

An example of something clearly presented and structured could be:

Activity X

Task X.1

Text here

Task X.2
…

Example 1