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

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

You can see your group allocation here.

The repository being inspected for this assignment is the Rust Programming Language

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.

Please note that for version management and ease of development, Git Extensions is a stand-alone UI application that may be used in place of GIT Kraken. In the file history section, it includes cloning a repository, navigating the file directory, filtering the committed logs using custom search input, and examining the committed logs and modifications made in comparison to the previous commit. You may obtain the user manual from https://gitextensions.github.io/.

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 coined by the 1994 book written by the “Gang of Four” 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”.

For this part of the assignment, we do not mind if you make smart use of the AI assistants like ChatGPT to help you identify the design patterns in Rust code as you may not be as familiar with the Rust code having seen design patterns presented in COMP 2100 in Java. However, you need to actually try your best to describe the identified design patterns yourself and justify what you find.

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.

NB! For a team of 4 you need 4 examples for each of task 3.1 and 3.2. Examples can each show a different thing.

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. 1 2 3 4

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 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#

  1. 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.
  2. 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.

  3. 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 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

Flutter example issue screenshot

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

Text here

Example 2

Text here

Issue cloning repository using GitKraken#

It appears that when cloning a repository directly through GitKraken, it attempts to fully resolve path names which may result in path too long error messages.

GitKraken path length error

This can be resolved by just cloning the the project repository using Git into the desired location on your device. For example:

git clone https://github.com/rust-lang/rust.git

Then opening the repository using GitKraken manually by navigating to the now locally cloned repository.

GitKraken open repo GitKraken navigate to repo

  1. “Replication Can Improve Prior Results: A GitHub Study of Pull Request Acceptance” Paper 

  2. “Gender differences and bias in open source: pull request acceptance of women versus men” Paper 

  3. “Attitudes, Beliefs, and Development Data Concerning Agile Software Development Practices” Paper 

  4. “Pull Request Decisions Explained: An Empirical Overview” Paper 

bars search times