-
Notifications
You must be signed in to change notification settings - Fork 1
First Outcobra Meetup 26. January 2017
Date: 26. January 2017
[TOC]
- Prioritization of the next features
- Technical planning of the next features
- Goals & Focus
- Work splitting / Lead developers
- Responsive design, apps and browser compatability
- Collaboration features
- Manage UI / Wizard
- Authorization filter
- Marketing / Business-model
- Code licensing
Task: Add a column to the user stories to mark them as 'done'
We set the priority like this:
- Marks
- Timetable
- Exams
- Holidays
Those are our core features. Everything else is a stretch goal (for now).
- Reporting is not part of the core features and is considered to be a stretch goal.
Implementation ideas:
- The "recursive modals" idea: Markgroups are shown like one mark and when you click on them, a new modal opens, which in turn shows the contained marks and groups, etc.
- The "one group level only" idea: We restrict the maximum nesting of markgroups to one (technically two) and just show the groups and marks in a list. A markgroup is one list item which contains the marks, next to each other.
We decided to settle for idea number two because of the following three reasons:
- We couldn't find a use case for nested mark groups
- Nested mark groups are a PITA frontend-wise
- It's easier for users if they don't have to worry about nesting of mark groups and if they see everything in one place.
Task: Update specification to reflect those changes
Task: Create mockups
Task: Create issues for the implementation of the marks
We are going to implement a week / calendar based view. For now, we are going to show all days, including the weekend, because some people have school on those days. At some point this should be a configuration option.
We are not implementing any kind of "time until the lesson is over" feature as a part of this. This will be implemented when we implement the dashboard.
For this to be doable, we need the timepicker (Issue 34). The person implementing this should check first if angular-material has a timepicker implemented by then.
Task: Create mockups
Task: Update specification to contains those more specific definitions
This is mostly basic CRUD functionality, needs an optional link to a mark and has to be shown on the dashboard.
Should be manageable from the timetable UI. Should otherwise be pretty simple to implement.
- We want to enter an open beta stage in August 2017. This is not to be regarded as a production version as in "this is our product as we want our final customers to experience it". It is more like a trial run in a smaller circle of people with the focus on getting feedback and improving user experience.
- We want to have quality assurance sprints at least every four sprints (as in
x o o o x, wherexis a QA sprint andois a normal "feature" sprint). A QA sprint has a length of one week by default. This can be extended to two weeks if necessary though. - We want to make sure that we can reach sprint commitments. This means we should not over-commit sprints.
Our motto is basically quality over quantity.
Quality means good code quality (reviews) and user experience.
- Frontend Lead
- Frontend Tooling
- Quality Assurance
- Backend Development
- Backend Tooling
- Database Administration
- IT-Operations
?
We want to make our WebApp responsive in a dedicated sprint. We want to do this in one of the next sprints as it will get harder to do this as our frontend grows bigger.
A native app will not be implemented for now. What we are planning to do is release an app that consists of a WebView which embeds our webapp. We can add notification functionality to this app.
While we are doing the responsive design sprint, we also want to focus on browser compatability for a while. Our main focus lies on modern browsers (Chrome, Firefox and potentially Edge).
Task: Create issues for responsive design, browser compatability and app (<- this won't be too soon)
Task: Create mockups for responsive pages
Task: Plan to implement Momentise all dates should be done in Sprint 8 or 9
Those will be discussed after all the core features have been implemented completely.
We will be discussing the wizard after the open beta. It will be important later when we have actual "users" but that's a different story.
A decision has been made that we'll be allowing the user to use subjects across multiple semesters. We haven't decided how we implement this yet though. The manage-ui shouldn't be affected by such a change. We also want to make schoolyears and semesters to be sort of clonable across multiple institutions and schoolclasses to enhance the UX (needs further discussion).
Task: Plan how to implement the subject-reuse
In a timeboxed manner, meaning half a sprint (one week), @needToRoll will be trying to fix the filter so that it works as intended. If he does not manage to get it working by then, we will be validating data manipulations on the service layer. This should be done before we start the open beta in August 2017.
Task: Plan Fix RequestFilter for one of the coming sprints, adding the above information
Not relevant at this point in time.
We want to use a license which does not allow other entities to use our product commercially. Also, they should not be able to provide a service for other users for free. The utilization under team members should be liberal though.
Task: Choose fitting license or write new one
| Task | Assignee | Done |
|---|---|---|
| Add a column to the user stories to mark them as 'done' | @needToRoll | ✔️ |
| Update marks specification to reflect the changes | @jmesserli | ⚫ (no changes needed) |
| Create mockups for the marks UI | @M4R1KU | ⚫ Will be done in the QA sprint |
| Create mockups for the timetable UI | @M4R1KU | ⚫ Will be done in the QA sprint |
| Update specification to contains those more specific definitions (timetable) | @jmesserli | ⚫ |
| Create issues for responsive design, browser compatability and app (<- this won't be too soon) | @jmesserli | ✔️ (created responsive, compat, app) |
| Create mockups for responsive pages | @M4R1KU | ✔️ |
| Plan to implement Momentise all dates (#81) should be done in Sprint 8 or 9 | @jmesserli | ✔️ (planned for Sprint 8) |
| Plan how to implement the subject-reuse | @needToRoll | ? ⚫ |
| Plan Fix RequestFilter (67) for one of the coming sprints, adding the above information | @needToRoll | ✔️ (attempt failed, issue created) |
| Choose fitting license or write new one | @outcobra/developers | ✔️ (created issue) |