Add funding-plan page

3 files changed, 238 insertions, 0 deletions

diff --git a/build.sh b/build.sh
index cd0114b..cf9f7dc 100755
--- a/build.sh
+++ b/build.sh
@@ -77,6 +77,8 @@ cp rdf/context.jsonld html/ns
 
 render html index "false"
 
+render html funding-plan "false"
+
 for file in $inputs; do
     render spec $file "true"
 done
diff --git a/html/funding-plan.md b/html/funding-plan.md
new file mode 100644
index 0000000..9f7b1de
--- /dev/null
+++ b/html/funding-plan.md
@@ -0,0 +1,235 @@
+# Specification (20 subtasks)
+
+The following subtasks involve research and writing of the technical
+specification.
+
+- **(S1)** C2S for the features already documented: a section of the
+  specification dedicated to the Client-to-Server protocol (C2S), with
+  description how commenting and how opening a ticket would be done in C2S.
+
+- **(S2)** Opening a merge request or patch: specification sections explaining
+  how a merge request and a patch would be created across servers.
+
+- **(S3)** Following, addressing, verified inbox forwarding: specification
+  sections defining the process of following forge-related objects and actors;
+  the required or recommended recipients for the various activities; a
+  mechanism for verified ActivityPub inbox forwarding.
+
+- **(S4)** Ticket dependencies: specification sections defining the process and
+  federation of creating ticket dependencies, hosting, and deleting them.
+
+- **(S5)** Ticket updates and flow: specification sections defining how
+  modifications of tickets are made, communicated and federated.
+
+- **(S6)** Merge requests and patches updates/flow: specification sections
+  defining how modifications of patches and Merge Requests are made,
+  communicated and federated, including new versions and including code review.
+
+- **(S7)** UI translation: specification sections defining how software user
+  interface localization management services (such as Weblate) would be
+  represented and interacted with in a federated manner, and how they would
+  interact with other forge objects, such as repositories and tickets.
+
+- **(S8)** VCS remote push: specification sections defining how users’ SSH keys
+  would be uploaded, represented and published, and the process of announcing
+  the pushing of commits to remotely-hosted repositories (i.e. ones hosted on
+  different servers than the user’s home instance) in a verifiable way.
+
+- **(S9)** Wiki: specification sections defining how wikis and pages would be
+  created, modified and deleted, and how wikis are integrated with other
+  project tools (eg. repository or tickets). This feature should integrate
+  XWiki if possible, since they are working on wiki federation.
+
+- **(S10)** Search, discovery, WebFinger, instance exploration: specification
+  sections defining how search and discovery of projects across the federated
+  network would work, whether/how the different types of actors would be
+  represented in WebFinger, and a representation of the public projects and
+  content that a server hosts.
+
+- **(S11)** Teams, groups, roles, access control: specification sections
+  defining how federated teams and groups would be created and modified, how
+  roles would be assigned to members, and how access controls would be defined,
+  enforced and announced.
+
+- **(S12)** CI, CD: specification sections defining how Continuous Integration
+  and Deployment services would communicate and interact with repositories.
+
+- **(S13)** Releases, packaging, package repos: specification sections defining
+  how packaged releases of repository content or content derived from it would
+  be created, published and manipulated, and linked with automatic CI builds.
+
+- **(S14)** Kanban: specification sections defining how kanbans and their
+  contents would be created, managed and federated.
+
+- **(S15)** Forks, stars, software specific vocabulary for repos: specification
+  sections defining how repositories could provide properties such as license,
+  programming language, dependencies, etc., and how forking and starring of
+  repositories is done, represented and communicated.
+
+- **(S16)** Verifiable builds: specification sections defining how software
+  builds would provide build recipes and hashes of the results to allow for
+  verifiable reproducible builds.
+
+- **(S17)** OCAPs: specification defining how Object Capabilities would be used
+  for authorization and access control in forges.
+
+- **(S18)** GPG key publishing and commit/tag signature verification:
+  specification sections defining how a user’s personal GPG keys would be
+  uploaded, published, used for verifying cryptographic signatures on commits
+  and tags within repositories, and used for signing other kinds of objects
+  such as tickets.
+
+- **(S19)** VCS specifics: specification defining the aspects of ForgeFed
+  specific or unique to each version control system, in particular Git and
+  Darcs, and how to use ForgeFed with these version control systems. If there’s
+  interest and feedback from the community, add Mercurial and/or SVN as well.
+
+- **(S20)** Migration/Import: specification defining how to migrate (or
+  “import”) a project from one instance to another including tickets, patches,
+  wikis, and every other objects pertaining to the project. Migrations will
+  allow complete “forks” of projects, and eliminate vendor lock-in.
+
+# Pagure (15 subtasks)
+
+The following subtasks are software development work which gradually implements
+federation in [Pagure](https://pagure.io/pagure).
+
+- **(P1)** Representation of ActivityPub actors for users, groups and
+  repositories: users, groups and repositories have JSON-LD representations
+  according to the specification, along with HTTP Signature keys for use when
+  signing activities.
+
+- **(P2)** Async delivery system: delivery of ActivityPub activities happens
+  asynchronously in the background, and failed deliveries are automatically
+  retried.
+
+- **(P3)** Discoverability of instances via NodeInfo/ServiceInfo and the
+  fediverse server discovery websites: implementation of NodeInfo/ServiceInfo
+  and other requirements for allowing Pagure instances to be crawled by
+  fediverse discovery websites like fediverse.party, fediverse.space,
+  the-federation.info.
+
+- **(P4)** Federated discussion, threads and comments: via ActivityPub S2S,
+  allow tickets and merge requests to receive comments from users of remote
+  ForgeFed servers, and also support discussion of remote issues and merge
+  requests.
+
+- **(P5)** Opening and closing a ticket: via ActivityPub S2S, allow repository
+  issues to be opened and closed by users of remote ForgeFed instances, and
+  allow opening and closing of remote issues.
+
+- **(P6)** Opening and closing a MR/patch: via ActivityPub S2S, allow merge
+  requests to be opened and closed by users of remote ForgeFed instances, and
+  allow opening and closing remote merge requests.
+
+- **(P7)** Following, addressing, inbox forwarding: users and repos can be
+  followed by remote users; users can follow remote users and repos; Pagure
+  performs ActivityPub inbox forwarding when expected to do so by other
+  ForgeFed servers.
+
+- **(P8)** Ticket dependencies: creation, deletion, hosting: issues can be
+  depended by remote issues, and can depend on remote issues, implemented
+  according to the specification.
+
+- **(P9)** Ticket updates/flow: issues can be modified by remote users, and
+  users can modify remote issues, including priority, milestones, labels,
+  assigned person.
+
+- **(P10)** MR/patch updates/flow: merge requests can be modified by remote
+  users, and users can modify remote merge requests.
+
+- **(P11)** VCS remote push and SSH key publishing: users’ SSH keys are
+  published according to the specification; commits can be pushed by local
+  users and by users of remote forges who have been given access, and both
+  local and remote push events are announced in a verifiable way according to
+  the specification.
+
+- **(P12)** Releases, forks and stars: repos can be forked and starred by
+  remote users; users can fork and star remote repos; repositories releases are
+  announced according to the specification.
+
+- **(P13)** Search, discovery, instance exploration: there are search and
+  exploration pages, and they can display both local and remote actors (users,
+  repositories).
+
+- **(P14)** Teams, groups, roles, access control: groups can have remote
+  members; users can become members of remote groups; roles and access controls
+  can be defined and assigned according to the specification.
+
+- **(P15)** OCAPs: Object Capabilities are used according to the specification,
+  for authorizing federated access to resource modification and to viewing
+  non-public resources.
+
+# Vervis (15 subtasks)
+
+The following subtasks are software development work which continues the
+implementation of federation in
+[Vervis](https://dev.angeley.es/s/fr33domlover/r/vervis).
+
+- **(V1)** Discoverability of instances via NodeInfo/ServiceInfo and the
+  fediverse server discovery websites: implementation of NodeInfo/ServiceInfo
+  and other requirements for allowing Vervis instances to be listed by
+  fediverse discovery websites like fediverse.party, fediverse.space,
+  the-federation.info.
+
+- **(V2)** Opening and closing a ticket: via ActivityPub S2S, allow issues to
+  be opened and closed by users of remote ForgeFed instances, and have some UI
+  for opening and closing remote issues.
+
+- **(V3)** Opening a MR/patch: via ActivityPub S2S, allow merge requests to be
+  opened and closed by users of remote ForgeFed instances, and have some UI for
+  opening and closing remote merge requests.
+
+- **(V4)** Ticket dependencies: creation, deletion, hosting: issues can be
+  depended by remote issues, and can depend on remote issues, implemented
+  according to the specification.
+
+- **(V5)** Ticket updates/flow: issues can be modified by remote users, and
+  users can modify remote issues, including priority, milestones, labels,
+  assigned person.
+
+- **(V6)** MR/patch updates/flow: merge requests can be modified by remote
+  users, and users can modify remote merge requests.
+
+- **(V7)** VCS remote push and SSH key publishing: user SSH keys are published
+  according to the specification; commits can be pushed by remote users who
+  have been given access, and the push is announced according to the
+  specification.
+
+- **(V8)** Releases, forks and stars: repos can be forked and starred by remote
+  users; users can fork and star remote repos; repo releases are announced
+  according to the specification.
+
+- **(V9)** Wiki: wikis and their contents can be created and manipulated by
+  remote users, ideally interoperating with XWiki federation.
+
+- **(V10)** Search, discovery, instance exploration: there are search and
+  exploration pages, and they can display both local repos and known remote
+  repos.
+
+- **(V11)** Teams, groups, roles, access control: teams can have remote
+  members; users can become members of remote teams; roles and access controls
+  can be defined and assigned according to the specification.
+
+- **(V12)** OCAPs: Object Capabilities are used according to the specification,
+  for authorizing federated access to resource modification and to viewing
+  non-public resources.
+
+- **(V13)** GPG key publishing and commit/tag signature verification: user’s
+  personal GPG keys can be uploaded, published, and used for verifying
+  cryptographic signatures on commits and tags according to the specification.
+
+- **(V14)** Client: development of a dynamic client application that supports
+  at least viewing and manipulation of tickets and merge requests, commenting,
+  viewing of repos and users, search and exploration, and communicates with the
+  Vervis server according to the specification, using ActivityPub C2S, OAuth2
+  and vocabulary defined in the specification.
+
+- **(V15)** Migration/Import: development of migration/import function for
+  repositories, tickets and other project data according to the specification.
+
+# Documentation (1 subtask)
+
+- **(D1)** Implementation guide: a detailed human-friendly document with
+  suggestions, recommendations and code examples, that guides developers in the
+  process of implementing ForgeFed in their own applications.
diff --git a/html/index.md b/html/index.md
index 30dc948..e9447cb 100644
--- a/html/index.md
+++ b/html/index.md
@@ -80,6 +80,7 @@ platform for testing the protocol and trying new features
 - [Issues tracker](https://notabug.org/peers/forgefed/issues)
 - [Wiki](https://notabug.org/peers/forgefed/wiki)
 - [Forum](https://talk.feneas.org/c/forgefed)
+- [Funding plan](/funding-plan.html)
 - Specifications:
     * [Behavior](/behavior.html)
     * [Modeling](/modeling.html)