Milestones, goals and funding plan #87
ForgeFed is getting NLNet funding. The funding is per milestone, so this is a good time to define our milestones and side projects, and get them discussed with NLNet.
Whenever more than one person is listed for an item, the order of people listed is simply alphabetical, not order of importance/authority/priority. Such things, if relevant, are mentioned explicitly.
Main responsibility: fr33domlover, zPlus
- At least 3 more drafts
- Final spec 1.0
- Spec components
- 3 core specs: Vocabulary, Modeling, Behavior
- Fediverse spec with details about real world usage on the Fediverse
- VCS spec with VCS specific details
- Any extras we need (reusable terms we define, OCAP specific stuff, data model of commits/patches, etc. whatever needs its own spec)
- Spec features
- Draft 1
- Representation of tickets and dependencies (DONE)
- Representation of MRs and patches (WIP)
- Discussion, comments, replies (DONE)
- Opening a ticket (DONE)
- Opening a MR/patch (WIP)
- VCS local push (WIP, ALMOST DONE)
- Draft 2
- C2S for the features from Draft 1
- Following, addressing, inbox forwarding (WIP)
- Ticket dependencies: creation, deletion
- Ticket updates/flow
- MR/patch updates/flow
- SSH key publishing (WIP)
- VCS remote push (WIP)
- Forks and stars
- Draft 3
- Ticket tracking remaining features
- Patches, MRs & code review remaining features
- Automatic patch listing a-la DarcsHub
- Search, discovery, WebFinger, instance exploration
- Teams, groups, roles, access control
- Draft 4
- CI, CD, releases, packaging
- Agile development sprint data, epics, gantts, SCRUM, WBS etc
- Software specific vocab, e.g. specifying the programming language, license, etc. of repos
- Reuse and integration of existing vocabs such as DOAP
- Verifiable builds
- GPG key publishing and commit/tag signature verification
- Reusable vocabulary and protocol components
- Git specifics
- Darcs specifics
- Mercurial specifics?
- Fossil specifics? Would Fossil benefit from ForgeFed?
- Email integration
- Draft 1
Docs and website
- The README and docs in our git repo (fr33domlover, zPlus)
- Implementation guide (fr33domlover)
- Design of ForgeFed website
- Vervis (fr33domlover)
- Demo for each feature
- Implement and adapt for each release
- UI design (ikomi, fr33domlover)
- UI implementation (ikomi, fr33domlover)
- Discoverability of instances via NodeInfo/ServiceInfo and the fediverse server discovery websites / our own
- Implement WebFinger for users
- Figure out WebFinger for non-user actors e.g. repos and projects
- Implement OAuth2 and C2S for client access
- Mobile client app, e.g. could use Tusky/Fedilab as starting point (anyone?)
Implementation in existing forges and ticket trackers
- Pagure (zPlus)
- Gitea (enot)
Non work expenses
- Hosting for website
- Hosting for Vervis instances
- Hosting for Pagure instances
- Attending Fediconf in Barcelona in 25-25 Sept 2020? fr33domlover, zPlus?
Dear people, please review this and let's try to fill the missing spots and grab the tasks you'd like to do (and get funding for them if you wish). I marked in bold what's missing/open.
People who have grabbed tasks, and their primary items:
- enot (Gitea federation)
- fr33domlover (spec, Vervis features and federation)
- ikomi (website, Vervis UI)
- zPlus (spec, Pagure federation)
Friendly reminder: This is not a contract. Just a plan. We'll be doing our best to make the world a little more beautiful :)
I'd be interested in working on gitea implementation.
Does anywhere provide notification if any of this is accomplished?
Everything related to the specifications is in this repository. The pagure implementation was published a year ago. Gitea federation did not happen at all and is now worked on independently. I don't know about vervis other than there was a partial implementation published some 18 months ago, IIRC.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?