TODO(July MVP)

• check the task list (@aravinth)
• set a number of hours next to each task (@loic @aravinth)

---

• Use Cases & User Research

Task list

Website

Logo (loic: 2h, aravinth: 2h) (owner: aravinth)

@aravinth: I hired a friend to create logos for mCaptcha(unpublished) and ForgeFlux, we can do the same to save time. He charges 1000INR(~13 Euros)/engagement.

Name (loic: 4h, aravinth: 2h) (owner: loic, aravinth)

Design (loic: 5h, aravinth: 10h) (owner: loic, aravinth)

@loic: my estimate is based on the idea that the web design is subcontracted via 99designs.com, upwork etc. @aravinth: my estimate is based on in-house design

Customer workflow (loic: 50h, aravinth: ?) (owner: loic)

@loic: this is everything required for a paying subscriber to subscribe and control the service that is rented, with the exception of the payment system part which is taken care of by the Payment System part of the Billing section. This includes web based workflow for account registration, password reminder, termination of the service, upgrading to get a more powerful machine, setting the DNS, etc. It is also where users can control the backups of their instances.

@aravinth's understanding of customer workflow: enables the sysadmin to spin up and maintain a forge instance and manage their account.

Sysadmin web control pannel

@loic: I propose there is none for the MVP, that's it is all CLI based.

Billing

This covers the development of the software and documentation required to allow a sysadmin to successfully deploy the billing part of the gitea hosted service. It includes whatever is necessary to control the actions of a paying client depending on its balance.

Payment system (loic: 120h, aravinth: 100h) (owner: aravinth)

@aravinth: the payment system will have the following features:

• generating custom invoices based on parameters supplied by sysadmins

• managing coupons and discount offers

• managing credit

• grace period before account is marked expired

• hooks to execute duing payment cycle events. Some of the events include:

  • pre-account expiry
  • pospt-account expiry
  • coupon cashed
  • payment success/failure
  • grace period begins for account
  • account running out of grace period

As part of the MVP, support will be implemented for Stripe integration

Linking with website and devops backend (loic: 40h, aravinth: 20h) (owner: loic, aravinth)

@aravinth: this includes utilizing hooks that are provided by the payments system to effect changes in various services that are offered

Documentation (loic: 24h) (owner: loic, aravinth)

@aravinth: documentation should include instructions to setup payments system in both Docker and bare metal^* setups and optionally include instructions to implement integration with a new payments provider(like Stripe) [*] I strongly believe we should include bare metal deployment instructions to avoid Discourse-like situations, where the only possible deployment is using Docker.

@loic: documentation includes detailed instructions that must be verified and tested multiple times to actually work as expected to setup the payment system. That is, for instance, create a stripe account, with screenshots, configure it in this way, with screenshots, get the token in this way with screenshots, copy the token in this file, etc. This is the only part of the payment system that cannot be made fully transparent to the sysadmin.

@aravinth: Agreed, my point supplements @loic's but what I meant was that, we should provide at least two deployment options(Docker and bare metal), instead of one(like Discourse)

Architecture & Planning (loic: 8h, aravinth: 20h) (owner: loic, aravinth)

Devops

This covers the development of the software and documentation required to allow a sysadmin to successfully deploy the gitea hosted service.

Gitea instance lifecycle backend (loic: 40h, aravinth: 20h) (owner: loic, aravinth)

@loic: this covers the creation of a gitea instance on behalf of a paying user. It is driven by the CRM: a new instance is created when a new user exists and has permissions to run a gitea instance. If the instance has a DNS setup for this user, the instance is configured to answer this DNS. If a user no longer has permission to run a gitea instance, it is suspended. It also takes care of backups and recovery.

Hosting Gitea instance lifecycle (loic: 40h, aravinth: 40h) (owner: loic)

@loic: this is the infrastructure as code the sysadmin will use when spawning a new hosting gitea service from scratch. They will follow instructions from the documentation and run commands from the CLI. When they are done they will get a new hosting gitea instance running at example.com and paying clients will be able to go there, subscribe to the service and get their gitea instance after paying with a credit card. This is also the infrastructure as code the sysadmin will use to upgrade their hosting gitea instance when a new release is published, with security patches etc or new features.

Ticket system for support (loic: 2h, aravinth: 20h) (owner: loic, aravinth)

@loic: this is work needed to run a ticket system for customers to file issues. It should be linked with the CRM so that only paying customers can file issues. But in the context of a MVP it is enough that a ticket system exists and there does not need to be restrictions: it can be open to anyone, reason why I think the time to make this happen is low

End to end testing (loic: 80h, aravinth: 50h) (owner: loic)

@loic: these are automated (emphasis on automated) end to end tests that (i) spawn a hosting gitea instance from scratch (ii) run scripts for each target use case (see use case). It may be quicker to do manual testing the first time around. But it will very quickly require documenting and running complex, lengthy manual testing. Or (and that's what really happens) there won't be proper testing and the whole system will very quickly be prone to regression and accumulate a technical debt it won't be able to pay in the very near future. Fortunately it can build on tooling created in the context of the enough.community project which has such end to end testing.

CI/CD (loic: 16h, aravinth: 10h) (owner: loic, aravinth)

@aravinth: my estimate includes my prior experience with Woodpecker CI and our need to write/improve already existing glue code for Gitea<-->Woodpecker integration. It does not include "ops" side of things(openstack? libvirt?). @loic: my estimate is based on my previous experience with Drone

Static site hosting(loic: 40h, aravinth: 40h)(owner: aravinth, loic)

@aravinth: estimate break down:

• custom domain routing: 5h
• config parsing: 5h
• Gitea integration: 10h
• ACME implementaiton: 20h

Shared hosting(loic: 124h, aravinth: 60h)(owner: aravinth)

system-wide per account resource usage monitoring: (loic: 24h, aravinth: 15h)

@aravinth: I'm not sure how this works, it is possible to monitor storage but what about compute power for CI/CD? @loic: there is no tooling for handling quotas in gitea, it will need specific development. It can be an external script monitoring just the content of the gitea repositories owned by a given user. It gets more complicated for organizations though.

data takeout/download (loic: 0h, aravinth: 30h)

@aravinth: I think support present in Gitea would be sufficient but I wonder how integrations are managed. Woodpecker CI uses webhooks to talk to Gitea, I'm not sure if Gitea exports webhooks as well. If it does, we'll probably have to search and replace old-woodpecker.example.com with new-woodpecker.example.com @loic: in the context of a MVP I think the existing migration process in Gitea is good enough.

payments integration (loic: 100h, aravinth: 15h)

@loic: the integration of permissions based on payment control in an automated way within the existing gitea codebase is significant work. I don't think it can be done exclusively via external scripts because it involves restricting what a user can do based on external information which is not something Gitea knows how to do at the moment. For instance if a user tries to login to the shared gitea instance, it should be notified that its subscription is about to expire and be offered a link to renew it. This could possibly be done by delegating authentication to an OAuth provider that enforces this policy. It would not require modifying gitea but it would require writing and running such a provider. In other words I'm not sure how to approach this but I sense the number of hours is closer to 100h than to 10h.

@aravinth: In Gitea, a user can have the following states:

• activated
• restricted
• admin
• sign in disabled

A crude payments integration can simply restrict(no idea what a restricted user's capabilities are) or can be denied sign in.

Docker registry hosting (loic: 24h, aravinth: ?) (owner:?)

@loic: I've never done that so I have no clue how to approach it. I would first have to research the simplest way to do that which is likely to take a full day with trial and errors. And then write an Ansible playbook to spawn the service. And then write and run tests to ensure it works as expected. I'm rather optimistic about this because it is likely something that comes up often and there maybe are simple solutions to self host a docker registry.

REMOVED: @KN4CK3R(Janis) is working on implementing Docker registry in Gitea

Documentation (loic: 24h) (owner: loic)

@loic: I would improve on the existing enough.community documentation which already targets the intended audience. There will be a "quick start part" with ideally a oneliner to setup the service for the first time. It may look like three full days to write a quick start is a long time. But from experience it is a feedback loop with development: the first time around the "quick start" is three pages long and requires 10 steps. Figuring out how to reduce the number of steps requires development so that it is sensible for the user and practical for the implementor.

Gitpad (@aravinth: 5h)(owner: @aravinth)

@aravinth: GitPad is MVP-ready. Code snippets uploads and comments are ready as of 14/03/2022 and only documentation is pending.

Operations

This covers provisioning and maintaining the resources required to develop and distribute the self hosted gitea hosting service.

Website (loic: 2h, aravinth: 10h) (owner: loic, aravinth)

@loic: this includes all the resources to run the infrastructure (bind, postfix, icinga, nginx) and the gitea hosting service web frontend that customers can use to rent gitea instances. It is small because it is fully automated via infrastructure as code: the bulk of the work is on the implementation of the infrastructure as code which makes the operation part seem very light.

Cloud provider procurement (loic: 1h, aravinth: 10h) (owner: loic)

@loic: opening an account at OVH.

Hardware procurement (loic: 2h, aravinth: 10h) (owner: loic, aravinth)

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.