🗓️ Date: 16/03/2014
🕖 Time: 17.00 - 18.30
📍 Location: Zoom || BM-A5
📝 Note Takers: Begüm Arslan, Mehmet Kuzulugil

• Aras Güngöre
• Begüm Arslan
• Cahid Enes Keleş via Zoom
• Egecan Serbester
• Halil İbrahim Gürbüz via Zoom
• Hasan Bingölbali
• Mehmet Emin İpekdal via Zoom
• Merve Gürbüz
• Ramazan Burak Sarıtaş
• Mehmet Kuzulugil
• NA Ersel Çanakçılı

1. Fixed meeting day time and place.
2. Ways to document weekly Effort of team and team members
3. Peer working - Should we do it?
4. Elaborate on requirements. Planning for the draft document. Refining the information about the project by the team
5. Tools and methods for the validation of the requirements. Specifically mockups
6. Our collaboration tools. Github and Discord. How and when we will use them.
7. Using discussions feature to decide on tasks. (Considering pros and cons)
8. Milestones

Final draft - Still the participants may check and add

1. Fixed MT
   1. Weekly meeting time: Thursday 18.00 Hall (Will be booked in advance)
2. Weekly reports
   1. Work reports will be issued weekly for the team.
   2. Team members should also record their efforts for the project
3. Peer working
   1. Peer working is ok. Members of the team will pair with one another for the benefit of information flow.
4. Requirements document
   1. Reviewed the structure of recent years' projects. Discussed about their significance for our specific task.
      1. A glossary will be presented before the effective content
      2. To be decided: A "concept map" may also be introduced. Some elements of the design may need to be defined.
      3. This schema is fine: Functional requirements (User Requirements, System Requirements), Non-functional requirements
   2. Reviewed groups' findings about the structure of the operation (via requirement elicitation). How to present these in the document.
   3. Best choice: Let's start and see. A first draft will be ready before saturday.
      1. Task sharing:
         1. Account features - Login, authentication, registration etc. Egecan, Begüm
         2. Profiles - Not only the general profile information about the users but some details about their operational roles Mehmet, Aras
         3. User Actions - We will also be defining (in an indirect way) the operations - Hasan, Merve, Burak
      2. About the details
         1. Account definitions is about the users. It is possible that system users with specific abilities (a doctor, a rescue expert, a diver) exist. But this information will be represented as a resource.
         2. User profile is not only a static and non-operational information about the user. Some operational roles (in the workflow and the work in the area) will also be stored in the user profiles and possible extensions to the software itself may be considered.
         3. User actions should be classified according to the "level of verification/reliability" of the users. User actions should be limited (or changed in effect) for unauthorized users self registering users.
         4. About the "admin" role. Should be elaborated. A power user with technical abilities? Or operational rights and roles?
         5. Application should not divert between mobile and web/desktop regarding functionalities.
         6. The definition of entities in the system will be documented in related user actions. Alternative: A conceptual glossary should be introduced in the document, defining the entities and data entries of the system. So the user actions simply refers to these definitions.
5. We will need the mockup tool later, so we have time. But "miro" is strongly recommended by members of the group.
6. Github and Discord use
   1. Issues in github. The group will communicate using discord to stimulate and inform members abount issues. "Issue completed" messages explicitly written to discord will keep the group updated. A new channel for this specific use in Discord?
7. Using discussions in github
   1. Seems an effective tool to resolve issues, finalize specific tasks (needing common knowledge and agreement)
   2. A Rules for Discussions page should be prepared/drafted
   3. We can finalize the RfD page after a discussion in discussions tool!
8. Github research: Milestones, discussions and Projects

During the meeting, some issues were raised by group members, but were only noted for future discussion. These will be noted here for clarity.

1. A workflow should be defined and presented to the Project Owner (This will support the validation) - [Mehmet Kuzulugil]
2. Dilemma: Any user and unauthorized guests should also benefit using the system vs. Security and protection are important so the software should not be available for the public domain. [Should be resolved later - best of both worlds solution is possible?]
3. "Good intention" for the users is assumed. But still ways to ensure the information provided by the users are to be designed.