Group Assignment 1: Inspection [75 MARKS]

Due date: 28th of August (Sunday) 2022, 11:59pm
Assignment Weighting: 20% of total grade
Starting the assignment: See the instructions
Submission: Submit your through Wattle - See further instructions below
Group Assignment 1 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

You can see your group allocation here.

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 Piazza 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 being inspected for this assignment is Spring Boot.

You are not expected, nor is it required to download and build Spring Boot to complete this assignment. If you wish to do so, you can follow the instructions for getting started. 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?

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.

A rough idea of how we will mark has been posted on Piazza.

Activity 1 [20 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. See slide 129 from week 4 lecture where it talks about version management and system integration.

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 assertain only that for which you have evidence.

Task 1.1 [10/20 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/20 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 handeled in a way that is consistent throughout the repository?

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 [20 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 [6/20 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 [6/20 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 Spring Boot project. 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 [8/20 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.

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.

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)

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 4 (on slides 12 and 13). Since your team has 4 to 6 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 [5 MARKS]#

Task 4.1 [5/5 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 Spring Boot 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

Submission Instructions#

You will be required to submit a single group report through Turnitin in PDF format on Wattle - Group Assignment 1 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 evalulate 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.

Do I get to choose my group?#

No, you must work in your allocated tutorial group.

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.

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.

A rough idea of how we will mark has been posted on Piazza.

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.

I’m stuck on task 3.3.#

You can take a look at this example from the Flutter repository. It would also be beneficial to look over the Week 4 Inspection slides again.

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