Project Management - Course Information

ENGR 301: 2019 Trimester 1

Expectations

ENGR 301 is a practice-based professional learning course, in a professional degree. Everyone is expected to exhibit professionalism in all aspects of their coursework whether or not those aspects are directly assessed.

Students

You must:

  1. Include your senior manager on all email communications with your client.
  2. Ensure that a senior manager is present at all meetings with your client.
  3. Participate in every meeting you attend with your client.
  4. Ensure that all project work is accessible to course staff for assessment and management purposes.
  5. Maintain a Project wiki Home page which lists the date, time and place of the next client-team meeting.
  6. Maintain a laboratory attendance log which lists dates, team members present and how long they were present. This log may be part of the Home page or it may be a separate page in the wiki which is linked from the Home page.
  7. Store the Project Charter, correct and complete, as a separate page in the Project wiki. The Charter should be linked from the wiki Home page.
  8. Use your real name and photograph in your GitLab and Mattermost profiles. All students are requested to upload a photograph to their profile.

Approved Storage Systems and Services

This section defines "University approved storage systems" and associated services for the purposes of the ENGR 301 Project Student Agreement, section 3.3.

University Approved Storage Systems and Services

Personal: desktop and laptop computers, tablets, phones, etc., owned by the student.
Organisational: ECS GitLab, ECS Mattermost

External Services Available with Prior Written Approval

The following services external to the University are available once prior written approval has been obtained from the Course Coordinator:

Heroku Team, Amazon Web Services, Google Firebase.

Approval to use other systems or services may also be given on a case-by-case basis, in writing, by the Course Coordinator. Approval is given on the condition that staff will have at least the same access as the student team to the external services for assessment and management purposes, which potentially includes post-delivery client support.

The obligation lies with the student team to ensure that all conditions of use are met.

Non-approved storage systems and services

The following services are strictly prohibited

Slack, Discord, Facebook, Google Drive, Dropbox, Trello, Heroku (personal), Amazon Web Services (personal), etc.

To understand why we have these restrictions (and to understand just who is taking what rights) consider this except from Google Drive's terms of use (as of March 2019):

When you upload, submit, store, send or receive content to or through Google Drive, you give Google a worldwide license to use, host, store, reproduce, modify, create derivative works (such as those resulting from translations, adaptations or other changes we make so that your content works better with our services), communicate, publish, publicly perform, publicly display and distribute such content. The rights you grant in this license are for the limited purpose of operating, promoting, and improving our services, and to develop new ones. This license continues even if you stop using our services unless you delete your content. Make sure you have the necessary rights to grant us this license for any content that you submit to Google Drive.

(Our emphasis) Note that these conditions breach many FLOSS licences, as well as obviously preventing any commercial, trade secret, or confidential information being stored or processed on such a service.

Project Monitoring and Control

Engagement with, and contribution to, projects are monitored through several means, including GitLab statistics and the use of a git repository inspection tool called Gitinspector. These tools, along with the direct observations of staff, are used to inform the marking of assessment items. Please note that only the master branch will be inspected.

Iterations, Reviews and Planning

Teams are expected to develop their project deliverables iteratively, and to determine an iteration length, or lengths for systems projects, which work well for their context. A rule of thumb, based on experience, is that 2-week iterations are good for most projects. A 2-week iteration allows four 4-hour lab sessions, equivalent to two 8-hour working days. The setting aside of a small amount of time for an iteration-end review and iteration-start planning is a highly recommended. These could take place in separate team meetings or in the same team meeting, teams are expected to develop review & planning strategies and practices which work well for their context. Use of the Planning Game dialogue sheets, provided in the Planning Game tutorial (see the Lecture Schedule) is, again, highly recommended.

GitLab and git Configuration

Please see the GitLab: Using the ECS Git Repo Tech Note for guidance on using the ECS GitLab for the first time. The preferred method of accessing git repositories within the ECS GitLab is via SSH, and guidance is available in the Tech Note and within GitLab for how to create an SSH key.

Branching Strategies

Teams are expected to develop a branching strategy that works well for their context, i.e. good practice; a good starting point for teams thinking about branching strategies is GitLab Flow which describes a best practice of:

create branch → develop → merge branch → delete branch.

Branches are expected to have lifetimes which are short on the time scale of an iteration (see Project Monitoring and Control above). Stale branches should be identified and removed.

Teams should also regularly discuss practices that help alleviate any problems and issues encountered with Merge Requests and should ensure that everyone knows the basic git commands for interacting with the Project repository.

git Commits

All students are expected to commit their work to their git repositories using their VUW email addresses and real names as their username either from a git GUI or from the command-line using the git config --global command, e.g.
$ git config --global user.name "user_name"
$ git config --global user.email "user_name@ecs.vuw.ac.nz"

Students who accidentally use different email addresses and/or usernames and thus risk having some of their contributions overlooked during assessment should create a .mailmap file to correct the situation. See the git-shortlog documentation for details on how to create and maintain .mailmap files.

Merge request approvers

Under Settings > General in your GitLab projects, there is a section called Merge request approvals which allows team members to change settings for approvals of merge requests. For example, teams can specify the number of approvals required for a merge request (default is 1) and a list of approvers (empty by default) that can approve the merge request. While you can add all your team members to the approvers list, it is advised to leave the approvers list empty. Leaving it empty effectively means that anyone that has access to the project would be allowed to approve the merge requests. Therefore, leaving the list empty would still allow any of your team members to approve merge requests.

Adding anyone as an approver also means they would be notified (by email) about changes to each merge request on the project. Teams should refrain from adding the ENGR300-2019 GitLab group as an approver as this not only contains the students, but also tutors and staff members. The tutors and staff members would not wish to receive these emails if this group were added as an approver.

Shared GitLab Runners

Please see the CI/CD section of your project, which should show the shared runners as seen in the screenshot below:

Shared Runners.png