Repository navigation
Home
After each team meeting, important decisions regarding development, architecture, workflow, communication, conventions, risks, and project organization should be recorded here.
The goal is to make team decisions easy to find and avoid ambiguity during development.
Development is organized around Git branches and Pull Requests (PRs).
Each Sprint task should normally be developed on its own branch. Changes are merged into the main branch through a Pull Request.
Work should be pushed regularly rather than only at the end of a Sprint. When early feedback would be useful, a Draft PR should be opened.
PRs should be submitted early enough for teammates to review them before the Sprint Review.
Every Pull Request must be reviewed and approved by at least one teammate before being merged.
The reviewer should review both the design and implementation and look for:
- Bugs
- Integration problems
- Maintainability issues
- Architecture/design problems
- Opportunities for improvement
For new features, particular attention should be given to architecture and integration with existing components.
A good Pull Request should follow this guide.
Review comments are written in English and should address the code rather than the author.
The following prefixes can be used:
- Important: should be addressed before merging
- Question: requires clarification or discussion
- Nitpick: minor suggestion that does not necessarily block the PR
The Scrum Master is responsible for ensuring that reviews are completed in a timely manner so that teammates are not blocked.
We use different communication channels depending on the type of discussion.
Telegram is the primary channel for:
- Quick questions
- Short discussions
- Status updates
- Notifying teammates about PRs requiring review
- Time-sensitive communication
Our private Discord server is used for longer technical discussions.
Dedicated channels should be used when a discussion or decision may need to be found again later.
Roamigo follows an architecture based on MVVM. Below is a high-level diagram (open it in a new tab) describing which parts of the app will communicate with which APIs:
The Figma design for Milestone M1 can be found here.
Each team member should plan approximately 17 hours per week for SwEnt.
Our approximate target distribution is:
- 12 h — implementation, testing, documentation, code reviews, task breakdown, estimation, and PR management
- 3 h — team/design/infrastructure work
- 1 h — Scrum-related work during the week
- 1 h — Friday Sprint Review, Retrospective, and Planning
This is a guideline rather than a strict allocation.
The Scrum Master (SM) and Product Owner (PO) roles rotate between team members from Sprint to Sprint.
Current role assignments should be visible on the Scrum board.
Risk planning is used to identify technical and organizational issues that could affect the development of Roamigo and to define mitigation strategies before these risks become blockers.
The main risks currently identified by the team are listed below.
Roamigo depends on several external services and APIs. These services may:
- Have usage limits
- Require payment
- Change their pricing
- Change their availability
- Not provide all the functionality required by the application
Before relying on an external service, the team should:
- Research its pricing and usage limits
- Verify that it provides the required functionality
- Test the service early in development
- Prefer services with free tiers suitable for development
- Avoid making core functionality depend too heavily on a single provider where possible
Some APIs may be difficult to integrate or may have incomplete or complex documentation. This could delay development.
For important external services, small proofs of concept should be developed early.
These prototypes should verify that:
- The API can be integrated into the Android application
- The required functionality is available
- The API behaves as expected
- Integration complexity is reasonable
Major features should not depend on an external API before its feasibility has been verified.
Roamigo should keep important trip information available even when the user does not have an Internet connection.
Synchronizing local and remote information may introduce inconsistencies.
The team should:
- Use Firestore's offline capabilities where appropriate
- Cache essential trip information locally
- Clearly distinguish between functionality that must work offline and functionality that requires Internet access
- Test synchronization behavior when the device reconnects
Tickets, reservations, bookings, and important itinerary information should receive particular attention because travelers may need them without network access.
Authentication, shared trips, user profiles, synchronization, and other collaborative features introduce backend complexity.
Some team members may also be less familiar with Firebase technologies.
Backend functionality should be introduced incrementally.
The team should:
- Start with simple Firebase Authentication functionality
- Begin with basic Firestore operations
- Add synchronization and sharing progressively
- Use the Firebase Emulator when appropriate
- Add automated tests for backend-related behavior where possible
Roamigo may contain sensitive information, including:
- Travel plans
- User profiles
- Location information
Incorrect permissions or security rules could expose this information to other users.
The team should follow these principles:
- Profiles and trips are private by default
- Firestore security rules are defined and tested before sharing functionality is introduced
- Privacy implications are reviewed when implementing social or location-based features
GPS information may be inaccurate, and determining whether travelers are nearby may be more complex than initially expected.
Location-based matching also introduces privacy concerns.
The team should:
- Make location sharing optional
- Avoid exposing precise user locations unnecessarily
- Share only the information required for traveler discovery
- Start with a simplified location model if the full matching system becomes too complex
The first implementation should favor simplicity and privacy over highly precise real-time matching.
Capturing and storing tickets or reservations introduces several potential issues:
- Large image sizes
- Camera permissions
- Storage requirements
- Sensitive documents
- Document-processing complexity
The team should:
- Request camera permission only when required
- Compress and store images appropriately
- Restrict document access to the owner or authorized users
- Begin with simple image storage before adding advanced document-recognition features
More advanced recognition functionality, such as OCR, should be introduced incrementally after basic ticket storage is working reliably.
Roamigo combines several significant areas of functionality:
- Travel wallet
- Ticket and reservation management
- Itinerary management
- Offline access
- Maps and routing
- Shared trips
- Expenses
- Traveler discovery and matching
Implementing all of these features within the available development time may be too ambitious.
Project scope is currently considered the highest-priority project risk.
The team will therefore develop Roamigo incrementally.
Priority should be given to:
- Core trip-management functionality
- Travel wallet functionality
- Tickets and reservations
- Important offline functionality
- Stable backend and synchronization behavior
More advanced functionality, such as traveler matching, may be simplified or deprioritized if necessary.
The objective is to have the application's core functionality working reliably before investing significant development time in more complex optional features.
Important decisions made during meetings should be recorded here.
The Wiki should be updated whenever the team makes a decision that affects how other members are expected to work.
After each team meeting:
- Identify new decisions.
- Add them to the relevant section of the Wiki.
- Add important decisions to the Decision Log.
- Update architectural sections if the architecture changed.
- Update conventions or procedures if the team agreed on a new process.
The Wiki should describe the team's current agreed way of working, while the Decision Log provides a history of how important decisions evolved.