Meeting with James 18 May - hamstar/Braincase GitHub Wiki

Agenda

###Actions from previous meeting on 11th May

  1. Do Vision Document
  2. Started Vision
  3. Design Decisions [From last meeting]
  4. Issues: https://github.com/hamstar/Braincase/issues?labels=design-decision
  5. Use Cases on backup security
    1. Completed #135
  6. Use cases for bandwidth usage
    1. Completed #133
  7. Draft of design/architecture document [Important]
  8. Google Document: https://docs.google.com/document/d/1d8Cjm2cnDrs1Zzx4BVgZ16DmRLkMXAvUMOaqNOQhcsI
  9. Architecture Diagram: https://cacoo.com/diagrams/PEiwmkbHlkveBpsA
  10. Acceptance Tests [Important] [From last meeting]
  11. Documented: https://docs.google.com/document/d/1gyrVAuQJ2rxn9O2rfnWQ9Aj9wI-rCMzQBnHXSBbnwyw
  12. Some ATs: https://github.com/hamstar/Braincase/issues?labels=acceptance-test
  13. Design Rational [From last meeting] (Design Decisions?)
  14. Issues: https://github.com/hamstar/Braincase/issues?labels=design-decision

Other

  1. Why are we responsible for doing the vision? This should be done by the client?
  • Without coming up with a vision for the software we won't be able to make effective decisions during the project. As professional software developers we should be capable of designing a vision for the client.
  1. What is the difference between design rationale and design decisions?
  • Design Rationale is why, Design Decision is what. We can mix them together in the issues but we need to make sure that the design rationale is under a separate heading lest we focus on the what instead of the why.
  1. Backing up a version controlled repository with normal files is surely folly?

Minutes

  • Vision should:
    • Express benefits that product will provide to the users
    • (develop ideas)
    • (protect intellectual property over time)
    • (augmentation of anyone interested in developing ideas)
    • With the product you are a more effective academic than without
  • Categories link ideas together
  • Possibly look at formalizing use case
  • Need to work harder to reach our goals each week
  • Reqs doc doesn't need to be completed to start
  • Start working on software review

##Issues

  • Make an issue for ATs

Actions for this meeting

  • Finish Vision
  • Separate design decision from rational
  • Issue on AT (#139)
  • Say for now we won't bother to do it in additional to UC, but we'll see whether QA measures seem to be required when feature releases
  • Finish software review