lab08 : Inter-Team Eval, Start Manual, User Stories and Issues towards Final Release, Retro 3

Start User Manual Document

Start a User Manual Document (as a Google Doc or another living document format of your choice) and link to it in a new ./docs/MANUAL.md file in your GitHub. It should start with a paragraph explaining the purpose and intended user audience for the product (it can share some of this information with your README.MD, but the manual should be entirely oriented towards end users and should make no mention of implementation details that are not relevant to the end user experience).

Team Roles and Github Contributions

We ask every team to comment on the code contributions that every team member made. You already documented leadership roles within the team management (in team/LEADERSHIP.md), and now we ask you to document the roles the team members played in the code development effort. You can comment on team contributions other than coding as well. In your github team folder, please create a contributions subfolder.

This lab just requires you to start the document in team/contributions/CONTRIBS.md, but you have until the final materials submissions deadline to update and edit it:
Document and write commentary on team member code (and/or other) contributions in team/contributions/CONTRIBS.md: each team member should initially write their own section.

• Suggestion: each team member should initially create a draft of their part in team/contributions/contrib_Alice.md, team/contributions/contrib_Bob.md, team/contributions/contrib_Carol.md, team/contributions/contrib_Danny.md…
• Then: the person asseembling the overall CONTRIBS.md report can copy/paste those separate files into one unified CONTRIBS.md file.
• Today: Review and discuss the /graphs/contributors report for your project repo.
  • You can find it by clicking “insights” then “contributors”.

Is the Contributors graph accurate?

Note that there can be disparities between the contributors graph and ground truth code contributions by teeam members. Some groups may have chosen to follow a pair programming approach, and consistently only one member may have done the commits. Or a team member may have used different github accounts when interacting with the code base. Whatever the situation, it is too late to fix the commits, but it’s NOT too late to offer an explanation in your team/contributions/CONTRIBS.md commentary.

• We are going to look at the data on the /graphs/contributors for your repo, but
• We are going to look more at your explanation of that data.

If the data and the explanation match, it’s all good.

If you have a team member that you know or suspect has made lots of commits that are not being attributed to them, scroll through your commit log and see if you can find a few examples.

If the commits look ok, but don’t tell the full story (e.g. a team member may have just contributed very few, but very important commits), you can bring that out in your commentary, too.

Even distribution of the coding effort among all team members is definitely not expected, but highly uneven contributions, especially when paired with potential team dissatisfaction expressed through the catme.org surveys is grounds for individual weighting of the project grade component among team members.

Third (and last) Retrospective

You will get time on Wed, 03/06, to hold your third and last team Scrum Retrospective, but you can move the time of this meeting to whatever time within this lab period your team prefers, including right this lab session (03/01). Note though that Monday lecture (03/04) will be taken up entirely by team activity towards inter-team product testing. Make sure you have a Retro leader assigned (should be the case since it was part of the Leadership review last lab).

You already know the goal and procedure for Retrospectives from your RETRO_01 and RETRO_02. This Retrospective allows you to discuss things that are relevant on your final stretch to product deployment, documentation, and presentation. Instead of designing an experiment this time, review what worked and what didn’t from previous meetings, and make strong commitments towards the final stretch of product development towards launch!

• In your team’s repo, under team/retrospectives directory, add a file RETRO_03.md (or whatever number you are at if you did other retros already) capturing the following:

  # Retrospective your-nr-goes-here, date-goes-here 

  * Led by: name-goes-here
  * Present: name1, name2, ... , nameN
  * Absent: name1, name2, ...

  ## Action item

  * a goal: identify something the team wants to get better at
  * a commitment: identify one thing that the team pledges to do to maximize productivity towards launch
  * a measurement: identify at least one way to assess and ensure that the commitment(s) is/are kept

  ## Optional

  * Record anything else you think the team might want to remember from this retro

• After the Retro

  Retro leader: add

  # Retro Assessment
  
  * A brief description of what retro outline or process you used.
  * A brief assessment of how it went.
  * What advice would you give to the next person leading a retro
    based on what you learned today?
  

# Rotate Exposed Secrets For this lab, repositories will be made public to non-team members. Any existing hardcoded secrets (API keys, passwords, access tokens, etc) in your application should be rotated out as soon as possible. In a bad-but-not-worst case scenario, a bad actor with credentials to your infrastructure can land you a large bill.

Most major cloud services offer dedicated solutions for securely managing secrets, so the appropriate place for your app depends on your chosen service. Some examples are:

• AWS: https://aws.amazon.com/secrets-manager
• Azure: https://azure.microsoft.com/en-us/products/key-vault
• GCP: https://cloud.google.com/security/products/secret-manager
• Heroku: https://devcenter.heroku.com/articles/config-vars
• GitHub Actions: https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions