.gitignore

@@ -1 +0,0 @@
-*~

README.md

@@ -1,14 +1,114 @@
 # TODO(July MVP)
 
 -   [x] check the task list (@aravinth)
--   [x] set a number of hours next to each task (@loic @aravinth)
+-   [ ] set a number of hours next to each task (@loic @aravinth)
+-   [ ] sort the tasks in the timeline so that it fits (@loic @aravinth)
 
 ---
 
-* [Use Cases & User Research](user-research)
+# Scope
+
+## Personae
+
+### Admin and billing
+
+Creates the instance, pays the bills, has admin rights allowing them to get backups, configure the DNS, terminate the instance, is the contact point for legal matters in case of abuse.
+
+### User
+
+Has an account on the gitea instance for administration purposes or is a non-privileged user.
+
+### Sysadmin
+
+Creates the hosting service, connects it to a resource provider (for instance OVH to get VM), connects it to a payment provider (for instance a stripe account linked to a bank account), answers support requests from Admin and billing, upgrades the hosting service.
+
+## Use cases
+
+### Hosting service Creation
+
+### Hosting service connection to a resource provider
+
+### Hosting service connection to a payment provider
+
+### Hosting service support request
+
+### Instance Creation
+
+### Instance DNS
+
+### Instance Grow
+
+### Instance Backup
+
+### Instance Termination
+
+### Instance Billing
+
+### Static pages
+
+Tasks:
+
+-   [Umbrella task tracking all related subtasks](https://tasks.batsense.net/tasks/269)
+-   [Custom domain routing](https://tasks.batsense.net/tasks/268)
+
+### Shared Instance:
+
+In the shared instance business model the customer will be paying for an account, rather than a separate instance.
+
+#### Motivation:
+
+Managed hosting is expensive and not everyone will be able to pay for it. A complete forge experience includes:
+
+-   CI/CD
+-   Static page hosting
+-   Docker registry
+-   Pastebin
+
+Hosting exclusive instances of all the above mentioned services can be very expensive. With shared hosting, customers will get the same forge experience for a modest subscription fee.
+
+#### Challenges:
+
+-   [@loïc stated that shared instance will pose moderation challenges as the provider will be responsible for the content hosted on it](https://matrix.to/#/!QdcnJXkpkBVpecQGtk:matrix.batsense.net/$0xJpEALLE46l-4UiybUaIBbThMvVdAGtfVPi9hxewow?via=matrix.batsense.net&via=matrix.org&via=t2bot.io)
+-   Payments integration and account side effects(activation, termination, etc.)
+
+#### References:
+
+-   [Matrix discussion](https://matrix.to/#/!QdcnJXkpkBVpecQGtk:matrix.batsense.net/$dR8nLlqcfZVAwwZkW5MafP2CvqYIzipemiJb3OOQWMY?via=matrix.batsense.net&via=matrix.org&via=t2bot.io)
+
+### CI/CD
+
+### Docker registry
+
+### GitPad: pastebin implementation
+
+### Abuse
 
 # Task list
 
+## User Research
+
+@loic: [User Research](https://jdittrich.github.io/userNeedResearchBook/) is arguably the most useful step in the software development lifecycle and also almost always overlooked. In a nutshell it aims at increasing, by an order of magnitude, the odds that the software being developped matches the expectations of the users. Even when the users are the developers of the software itself.
+
+### Question: why and how does someone create and use a self hosted Gitea hosting service? (loic: 2h, aravinth: 2h) (owner: loic)
+
+@loic: this focuses on the experience of the sysadmin personae rather than the "Admin and billing" because most of the work done in the task list is for their benefit. If there was enough time, it would be useful to do user research based on a question focused on "Admin and billing". But given the limited resources we have, I think reasonable to narrow the focus in this way.
+
+### Use Cases and Personae (loic: 3h, aravinth: 3h) (owner: loic)
+
+@loic: the Use Cases above roughly list what the service is going to provide, from the point of view of each personae. It will be necessary to explain them with scenarios in the style of: "As a sysadmin... I will do this and I expect that".
+
+### Interviews (loic: 16h, aravinth: 5h) (owner: loic)
+
+@loic: the first step is to write interview scripts. The goal is that the interviewee tells us about its past experience. The script is guided by the question and the use cases: it helps drive the conversation so that the interviewee tells about his personal experience in the hope that it indirectly provides answers to the "why and how" question. Three interviewees must be recruited, appointments made, interview done, sessions recorded and transcribed.
+
+### Analysis (loic: 5h, aravinth: 5h) (owner: loic, aravinth)
+
+@loic: since this analysis cannot be done in person with actual post-its, it can be done online, during half a day. It essentially consists of grouping statements from all three interviews. They are narrative in nature and by isolating statements we want to break free of this narrative. We do that separately and then we discuss on how to merge those groups and why. And then we assign them priorities.
+
+### Report (loic: 2h, aravinth: 5h) (owner: loic, aravinth)
+
+@loic: this is a summary of the analysis session above that does not present the opinion of the writer. It summarizes the findings of the session and explains it based on what is found in the interviews. If something cannot be grounded in phrases found in the interviews, it is not part of the report. The outcome is a list of themes, sorted by priority. It tells the developer about what matters most to the user targetted by the question that is central to the user research, in this case the sysadmin. It is also a good way to explain to newcomes why the project went in this direction and not another, why it was felt more important to work on this aspect rather than another.
+
 ## Website
 
 ### Logo (loic: 2h, aravinth: 2h) (owner: aravinth)
@@ -163,3 +263,12 @@ This covers provisioning and maintaining the resources required to develop and d
 ### Release management (loic: 8h, aravinth: 24h) (owner: loic, aravinth)
 
 @loic: I assume the software stack + documentation will be python based because that's the language we're both familiar with. And there will be some docker image wrapping this because the devops part of things has lots of dependencies, in the same way enough.community does. The release management is about publishing the software stack on pypi, the documentation on rtd and the docker images on the docker hub.
+
+# Timeline
+
+## Static pages: 15/03 - 31/03(@aravinth)
+
+-   [ ] Custom domain routing(15/03 - 23/03)
+-   [ ] Configuration parsing from repository (23/03 - 24/03)
+-   [ ] ACME implementation for TLS certificates (25/03)
+-   [ ] Website preview on pull requests (26/03 - 31/03)