ci/woodpecker/push/woodpecker Pipeline was successfulDetails
This PR defines the sequence of activities for adding a component (e.g. a repo, an issue tracker, etc.) to a project. And the process of removal.
The adding process is implemented in Vervis (it took me a while, was more complicated than I hoped). I haven't yet fully implemented the removal, but it seems simple enough to include in this PR for completeness.
Reviewed-on: #210
Reviewed-by: Aravinth Manivannan <realaravinth@noreply.codeberg.org>
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Pere Lev <pere@towards.vision>
Co-committed-by: Pere Lev <pere@towards.vision>
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
This is about creating Projects, adding components to them, and using the Project access to use the components. With a video demo and (hopefully) interactive Vervis demo deployment.
Reviewed-on: #211
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Reviewed-by: Anthony Wang <xy@noreply.codeberg.org>
Co-authored-by: Pere Lev <pere@towards.vision>
Co-committed-by: Pere Lev <pere@towards.vision>
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
Depends on #199 and includes its commit
This also updates the vocabulary description of `Revoke`, removing properties that aren't used anymore
Reviewed-on: #201
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Pere Lev <pere@towards.vision>
Co-committed-by: Pere Lev <pere@towards.vision>
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
Until now, Revoke activities were allowed to "copy" properties from the
Grants they cancel, because the only embedded signing method on the
Fediverse was based on JSON-LD algorithms and linked data signing (which
are both controversial).
With the object integrity FEP that came in 2022, which is based on plain-JSON
signing and doesn't depend on JSON-LD, we now have a better option.
This PR removes the "copying" of properties from Grant to Revoke,
instead allowing a Revoke to include entire Grant objects, signed using
the method described in the FEP.
Reviewed-on: #199
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Pere Lev <pere@towards.vision>
Co-committed-by: Pere Lev <pere@towards.vision>
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
(This is just #198 rebased on top of the latest main branch)
Until now, every use of a Grant delegation chain required checking all
the revocation URIs by sending HTTP requests to them. For deeply nested
structures of projects and teams, or for very big projects and teams,
this may cause a lot of network traffic for every resource access, and pressure
on the revocation URIs, and may require very high availability of the
servers hosting those URIs.
This commit allows a Grant to specify a duration, in seconds, such that
the revocation URI check may be skipped if the duration hasn't passed
since the last check of the URI (by the specific actor or by the whole
server). This allows to reduce the impacts described above.
Co-authored-by: Pere Lev <pere@towards.vision>
Reviewed-on: #208
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
So far, `Grant` activities don't have explicit time bounds:
- Once published, they're instantly valid
- Once published, they're valid forever unless manually revoked at some point
This PR adds support for specifying a start time and an expiration time for `Grant`s, using the standard ActivityPub `startTime` and `endTime` properties.
Reviewed-on: #197
Reviewed-by: Anthony Wang <xy@noreply.codeberg.org>
Co-authored-by: Pere Lev <pere@towards.vision>
Co-committed-by: Pere Lev <pere@towards.vision>
ci/woodpecker/manual/woodpecker Pipeline was successfulDetails
ci/woodpecker/deployment/woodpecker Pipeline was successfulDetails
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
The current CI pipeline was a workaround for Codeberg-CI/feedback#117 and is currently broken. This PR makes it use Alpine and pipx instead which should be more reliable.
Reviewed-on: #206
Co-authored-by: Anthony Wang <a@exozy.me>
Co-committed-by: Anthony Wang <a@exozy.me>
To prevent issues like #204 in the future auto discovery of the atom feed can be useful. This is a simple change based on [these docs](https://www.getzola.org/documentation/templates/feeds/).
Reviewed-on: #205
Reviewed-by: Anthony Wang <xy@noreply.codeberg.org>
Co-authored-by: Sertonix <sertonix@noreply.codeberg.org>
Co-committed-by: Sertonix <sertonix@noreply.codeberg.org>
A very little post about Inviting people to be collaborators in projects.
Co-authored-by: Pere Lev <pere@towards.vision>
Reviewed-on: #202
Reviewed-by: Anthony Wang <xy@noreply.codeberg.org>
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Pere Lev <fr33domlover@noreply.codeberg.org>
Co-committed-by: Pere Lev <fr33domlover@noreply.codeberg.org>
.
Co-authored-by: Pere Lev <pere@towards.vision>
Reviewed-on: #200
Reviewed-by: Anthony Wang <xy@noreply.codeberg.org>
Co-authored-by: Pere Lev <fr33domlover@noreply.codeberg.org>
Co-committed-by: Pere Lev <fr33domlover@noreply.codeberg.org>
The CI currently takes 40 minutes to run and times out when trying to deploy the website, which is a huge blocker. For some reason, using `archlinux` as the container image fixes the slowness problem, but this is only a temporary fix since using `debian` will be more stable in the long run.
Co-authored-by: Anthony Wang <a@exozy.me>
Reviewed-on: #192
Switching from plain pandoc to a static site generator was discussed in #110. Finally, here it is.
- I didn't use any theme, just kept the CSS we already have
- Removed the funding-plan page, it's outdated
- Added a blog section
@xy, can you verify that the CI/deployment recipes are correct and run successfully? Do you have access to the Woodpecker instance (looks like I don't)
The live website still doesn't have the latest changes applied, and Idk if it's because of CI waiting in the queue, or because of CI recipe having an error.
Co-authored-by: fr33domlover <fr33domlover@riseup.net>
Reviewed-on: #191
Reviewed-by: Anthony Wang <xy@noreply.codeberg.org>
Co-authored-by: fr33domlover <fr33domlover@noreply.codeberg.org>
Co-committed-by: fr33domlover <fr33domlover@noreply.codeberg.org>
As discussed on Matrix, this PR merges the 3 specs into a single spec document. If anyone missed that piece and doesn't feel comfortable with a merge, comment below!
This PR also switches the spec from plain Pandoc Markdown into the format of [Bikeshed](https://tabatkins.github.io/bikeshed), a tool that generates pretty interlinked standard specifications.
Bikeshed files have a `.bs` extension. You can ask your text editor to highlight them as Markdown (the formats differ, but for highlighting purposes this works nicely).
The spec will now live in the `spec.bs` file, which is rendered into `html/spec/index.html` and thus will be accessible at `https://forgefed.org/spec`.
**I suspect this huge PR is difficult to review. Since there's low activity here, I'm asking for your trust, that this PR changes only the *layout* of the info, and doesn't change anything at all about the vocabulary or processes. I copied them as-is, only making formatting tweaks for Bikeshed to render them properly.**
Now (March 12) I'm finally taking it out of WIP status and I'm going to give it a while. If no strong concerns appear, I'll probably merge it in a week or two, and move forward to the NLNet-funded tasks and lots of exciting stuff waiting for us in 2023!
Other/missing stuff for separate PRs:
- Tweak the color scheme based on the ForgeFed website CSS?
- Custom tweak via Bikeshed to add light/dark theme switch?
Co-authored-by: fr33domlover <fr33domlover@riseup.net>
Reviewed-on: #186
Reviewed-by: Anthony Wang <xy@noreply.codeberg.org>
Co-authored-by: fr33domlover <fr33domlover@noreply.codeberg.org>
Co-committed-by: fr33domlover <fr33domlover@noreply.codeberg.org>
- Vocabulary: Add the 'Patch' type
- Modeling: Describe how to represent a Patch and a Merge Request
- Behavior: Describe how to open a Merge Request
See #169 (open in private browsing if you get an error) for more info about why this PR is designed the way it is.
Co-authored-by: fr33domlover <fr33domlover@riseup.net>
Reviewed-on: #185
Overview:
- So far, the authorization system allows resources to grant access directly to people
- But in a situation of projects, teams, hierarchy of projects, hierarchy of teams etc. we need a flexible and efficient way for access rights to flow between actors
- This PR adds a delegation chain mechanisn, allowing actors to receive access and then pass it on to other actors, who can then use it to manipulate the resource (and/or pass it on to even more actors)
- Delegation is a standard feature of Object Capability based systems
- The delegation mechanism in this PR doesn't just allow anyone to freely delegate; it allows delegation in the way relevant to forge federation: Basically, repos/trackers/tools/services delegate to projects, which delegate to teams, which delegate to people
(This PR used to be #166, due to a Codeberg error I had to close it and reopen a fresh PR)
Co-authored-by: fr33domlover <fr33domlover@riseup.net>
Reviewed-on: #184
Reviewed-by: Anthony Wang <xy@noreply.codeberg.org>
I also renamed COPYING to LICENSE since that seems to be a more typical name for it, and removed a lot of unneeded entries from the .gitignore.
For the README and website, index.md, I mostly replaced the website's contents with text from the README and deleted a lot of old or duplicated information. For instance, I removed the project links at the bottom of the website since there are links to them at the top. Overall, I tried to make the website itself to be non-technical and a good introduction to what ForgeFed is, and then keep technical information in the README of the repo.
This also (hopefully) fixes#132, the missing emojis issue. You can see a live demo of this PR at https://forgefed.exozy.me to verify for yourself if the emojis are working now.
Co-authored-by: Anthony Wang <a@exozy.me>
Reviewed-on: #187
Co-authored-by: Anthony Wang <xy@noreply.codeberg.org>
Co-committed-by: Anthony Wang <xy@noreply.codeberg.org>
Co-authored-by: Anthony Wang <a@exozy.me>
Reviewed-on: #181
Reviewed-by: Aravinth Manivannan <realaravinth@noreply.codeberg.org>
Reviewed-by: fr33domlover <fr33domlover@noreply.codeberg.org>
Co-authored-by: Anthony Wang <xy@noreply.codeberg.org>
Co-committed-by: Anthony Wang <xy@noreply.codeberg.org>
The `Team` type represents a group of people working together. Each team member has a role within the team. Teams can be given access to projects and to their components, and the access is passed to the team members, based on their role.
---
Q1: Why isn't Team a subtype of Group?
A: I'm considering that, right now no actual benefit, see #163
Q2: Why do teams inherit access *to* their subteams, rather than collecting access *from* their subteams?
A: Because that's what makes sense for how humans organize in teams. The opposite creates a situation where the people at the top can access everyone's stuff, *and* keep stuff that nobody else can access. The option I picked is the "people power" option, where the people in the small subteams get the general access that the parent team has (stuff the whole organization shares together), and then they get to have their own stuff that they control. In other words, control flows towards the people with the skills and trust, rather than towards the people who happen to be first and enforce a hierarchy upon others. It may sound like a visionary thing, but it's actually the same way github lets orgs define teams.
Q3: Why use a custom property `subteams` for children, but the AS2 `context` for parents?
A: Because there's no good match for the children property in AS2 (I also looked at some RDF ontologies but couldn't find anything that really felt right). I'm considering to use a custom property for parents too, just for consistency, but not sure. `context` should work.
Q4: Why does `subteams` map to a `Collection` while `context` just lists parents without a `Collection`?
A: There aren't clear guidelines for when to use a `Collection`, when to use an RDF `List` and when to use a simple multiple-values-for-a-property, but I'm observing a pattern that's used in AP, e.g. with `replies` and `inReplyTo`, and which makes sense to me:
In a nested structure where parents have the authority about who their children are (because they provide them some service), and where parents can have many children but children have few parents,
- the parents list the children using a `Collection` that can be paginated and items can be added and removed,
- while the children, mostly just for information, list the parents they have and whose services they use.
Parent teams provide a service to subteams: They delegate to them access to resources. And teams can have many children, but probably few parents, probably just 1 in mose cases. So, it fits the case described above. It also works the same with ForgeFed's ticket dependencies, for a similar reason.
**This PR is the 2nd in a series of 4 related PRs:**
1. #163: Add the Project type
2. #165 (i.e. this PR): Add the Team type
3. #166: Describe grant delegation system (we need it for access control for projects and teams)
4. (Not opened yet) Describe access controls for projects and teams:
- Add (or remove) Person to Project
- Add (or remove) Team to Project
- Add (or remove) a component (e.g. Repository) to a Project
- Add (or remove) a Team to a component (e.g. Repository)
- How grant delegation is used in all of these
1 and 2 are quite simple but 3 and 4 are going to be complicated, so I'm splitting to 4 to make review easier :-)
Co-authored-by: fr33domlover <fr33domlover@riseup.net>
Reviewed-on: #165
Reviewed-by: Anthony Wang <xy@noreply.codeberg.org>
The `Project` type is a way to group and nest forge/FSDL component
actors, e.g. Repository, TicketTracker, PatchTracker, etc. for several
purposes:
- Covenient grouped display in UI when browsing, exploring, searching
- Easy management for project team members
- Possibility to grant/delegate OCAPs to a whole projecr rather than do
it individually to every component, which is cumbersome and messy
Properties `components` and `subprojects` are added as well.
Q1: Why isn't Project a subtype of the AS2 Group?
A: ActivityPub doesn't define any behaviors for Group, so the main benefit of this would be to share behavior with usage of Group on the Fediverse. This can be advantage (if the behaviors are aligned) but can also cause problems (if the behaviors conflict). I know people are doing group related things on the Fediverse, but I'm not personally aware of something established, so I prefer to protect us from conflicts for now. At any point, if it becomes helpful, we can make Project extend Group.
Q2: Why use a custom property `subprojects` for children, but the AS2 `context` for parents?
A: Because there's no good match for the children property in AS2 (I also looked at some RDF ontologies but couldn't find anything that really felt right). I'm considering to use a custom property for parents too, just for consistency, but not sure. `context` should work.
Q3: Why does `subprojects` map to a `Collection` while `context` just lists parents without a `Collection`?
A: There aren't clear guidelines for when to use a `Collection`, when to use an RDF `List` and when to use a simple multiple-values-for-a-property, but I'm observing a pattern that's used in AP, e.g. with `replies` and `inReplyTo`, and which makes sense to me:
In a nested structure where parents have the authority about who their children are (because they provide them some service), and where parents can have many children but children have few parents,
- the parents list the children using a `Collection` that can be paginated and items can be added and removed,
- while the children, mostly just for information, list the parents they have and whose services they use.
Parent projects provide a service to subprojects: They delegate access-to-them to relevant teams and people. And projects can have many children, but probably few parents, probably just 1 in mose cases. So, it fits the case described above. It also works the same with ForgeFed's ticket dependencies, for a similar reason.
Co-authored-by: fr33domlover <fr33domlover@riseup.net>
Reviewed-on: #163
Reviewed-by: Aravinth Manivannan <realaravinth@noreply.codeberg.org>
`mirrors` is meant to represent GitHub and Gitea's concept of mirrors
(respectively called `mirror_url` and `original_url` in their API);
as well as GitLab's pull mirrors (not present in the API, besides a
boolean state).
`mirroredBy` is its inverse property for the sake of completeness.
`mirrorsTo` is meant to represent GitLab's push mirrors (which GitHub
and Gitea don't have); and `mirroredFrom` is its inverse property.
These properties are meant to informational (part of #130),
rather than trigger actions from/to other repositories.
Co-authored-by: Valentin Lorentz <vlorentz@softwareheritage.org>
Reviewed-on: #148
Reviewed-by: fr33domlover <fr33domlover@noreply.codeberg.org>
Reviewed-by: Anthony Wang <xy@noreply.codeberg.org>
Co-authored-by: Val Lorentz <_zn3val@noreply.codeberg.org>
Co-committed-by: Val Lorentz <_zn3val@noreply.codeberg.org>
If Bob asks for access to MyProject, possibly Alice approves using an
Accept and then MyProject sends a Grant. But what if Alice doesn't trust
Bob? Until now, her only option was:
1. Alice sees the Join that Bob sent, and decides not to send an Accept
2. Celine sees the Join, doesn't know that Alice doesn't trust Bob, and
decides to send an Accept
3. MyProject sends a Grant
4. Alice notices what happened and is now surprised and upset...
This commit gives Alice a better option:
1. Alice sees the Join, and decides to sent a Reject
2. If Celine doesn't notice the Reject and sends an Accept, MyProject
refuses to send a Grant because it considers the Join already
rejected by Alice
3. Alice, Bob and Celine can now talk and figure out if/how Bob can join
and contribute
Co-authored-by: fr33domlover <fr33domlover@riseup.net>
Reviewed-on: #162
Reviewed-by: Anthony Wang <xy@noreply.codeberg.org>
The Invite->Accept->Grant flow allowed people to invite other people to
access a resource. What if I want to request access for myself?
This commit adds the Join->Accept->Grant flow, allowing people to
request and receive access to a resource.
Co-authored-by: fr33domlover <fr33domlover@riseup.net>
Reviewed-on: #161
Reviewed-by: Anthony Wang <xy@noreply.codeberg.org>
In a recent PR, I introduced the `Grant` activity.
This PR explains in much more detail how and when to use it, including how to offer access to shared resources using `Invite` activities.
2 things are still left missing in the OCAP system:
- How to define and specify roles *(because I'm still researching that)*
- How to send grants to collection-managing objects, which then *delegate* the access to their members and subcollections (e.g. invite a team to a repo, and team delegates the grant to its members) *(because it's a more complicated aspect that I'm still designing and going through rounds of feedback in our Matrix room and on SocialHub)*
Those missing parts will come soon in separate PRs when they're ready :-)
Co-authored-by: fr33domlover <fr33domlover@riseup.net>
Reviewed-on: #160
Reviewed-by: Anthony Wang <xy@noreply.codeberg.org>
When an ActivityPub client or server wants to interact with some remote
object, it needs to identify *which actor controls this object*, and
send the activity (at least) to that actor. Right now, as far as I can
tell, the way to identify that actor is case-specific:
- When commenting on a Note, notify the Note's `attributedTo`
- When interacting with a Ticket, its `context` specifies the tracker
actor
- When interacting with a Commit, its `context` specifies the Repository
that contains it
- When sending a Grant providing access to some resource... hmm no
generic way to determine who the actor (who controls the resource) is!
Q: Why not use the `context` property for this?
A: Because it's a standard general-purpose commonly used/abused/overloaded
property. It's much safer and more friendly to have a dedicated property
for this, allowing devs to continue using `context` for whatever stuff
they're already using it for.
Q: `managedBy` isn't specific to forges, why put it in ForgeFed?
A: It's indeed not specific to forges. At a later time, I'd like it to
be elsewhere, in its own spec or Fediverse Enhancement Proposal. For
now, to make it already available for experimentation and implementation, for
now it's in ForgeFed, along with some other properties and types (such as
Grant).
Co-authored-by: fr33domlover <fr33domlover@riseup.net>
Reviewed-on: #159
Reviewed-by: Anthony Wang <xy@noreply.codeberg.org>
Rather than being flexible and ambigious about types of actors, the spec
now clearly specifies 3 forge related actor types:
- Repository, which already existed
- The now added TicketTracker
- The now added PatchTracker
There are other actor types such as Person of course, but Person is a
standard ActivityPub type so we don't need to define it in ForgeFed :)
On forges like Gitea and GitLab, projects contain all of those 3
types of components, but any other combination is valid and supported.
In addition to adding the actor types:
- Ticket's 'context' in the Modeling spec requires the context to be a
TicketTracker or a PatchTracker (but I haven't used the MUST word...
yet, just in case some unexpected use case comes up)
- In the Behavior spec, I removed the section talking about flexibility
of actors because explicit actor types are now provided instead (yay,
simpler life)
Co-authored-by: fr33domlover <fr33domlover@riseup.net>
Reviewed-on: #157
Reviewed-by: Anthony Wang <xy@noreply.codeberg.org>
Adding a new activity type `Grant`, used for granting access to shared
resources (repos, ticket trackers, etc.) and some related proeprties:
- `fulfills`, for automatic access delegations to specify which manually
sent Grant triggered them (allows to group grants in UI, display them
in a way that makes sense to human users, and avoid unmanageable mess)
- `capability`, for activities to provide authentication by specifying a
previously published `Grant` as proof of access (it's called
capability because it's an Object Capability)
I'm not adding `Grant` to the Behavior spec yet because the explanation
will rely on types that haven't been added yet, such as `TicketTracker`.
I'll add them in a separate PR and then I'll add a Behavior section
for `Grant`
Co-authored-by: fr33domlover <fr33domlover@riseup.net>
Reviewed-on: #156
Reviewed-by: Anthony Wang <xy@noreply.codeberg.org>
Co-authored-by: fr33domlover <fr33domlover@noreply.codeberg.org>
Co-committed-by: fr33domlover <fr33domlover@noreply.codeberg.org>
So far there have been 2 ways to ask to create an object on another
server:
- The Offer flow, which means the receiving side will be hosting the
object. This means e.g. repos would be hosting their tickets, on the
same server. This is the easy and obvious option.
- The Create flow, which means the author hosts the object, and the
receiving side will just remember its ID, but the receiving side is
also the one responsible for specifying access control.
The Create flow has existed because of the deeper distribution is
allows, where objects and their child objects can live on different
servers. It also allows users to host their own tickets, much like they
host their own comments and messages. But it's a challenge because
actors can't entirely reliably enforce access rules and integrity rules
on child objects hosted elsewhere. Having 2 flows also adds complexity
to implementations.
After a lot of thinking, I decided I wish to remove the Create flow. It's a
huge simplification to the specification and to implementations. The
mitigation for losing the advantages of the Create flow is:
- The kind of decentralization on the Fediverse isn't a fully
distributed situation, and in particular it doesn't help with remotely
enforcing access control. If/when the fediverse goes fully P2P, it
will surely have such mechanisms. I believe actor-level decentralization is
*definitely* enough to solve the problems of centralization that we have with repo hosting websites. It's also
probably the best that's reasonably available to us without resorting
to p2p and cryptography based solutions.
- If people want to host their own tickets, then can create a personal
ticket tracker and use it as their to-do list or as a place to list
bugs that got rejected by the relevant projects, or whatever people
want to use personal tickets for
- Actor-level decentralization is simple, clear, easy and elegant, and I don't
believe we really need anything more complicated
I implemented the Create flow on Vervis. It added huge complexity. I'm now busy removing it, suffering the complexity of removing all that stuff entangled in my code... :P and seeing how much simpler things were before I implemented it "^\_^
Co-authored-by: fr33domlover <fr33domlover@riseup.net>
Reviewed-on: #155
Reviewed-by: Anthony Wang <ta180m@noreply.codeberg.org>
Co-authored-by: fr33domlover <fr33domlover@noreply.codeberg.org>
Co-committed-by: fr33domlover <fr33domlover@noreply.codeberg.org>
ci/woodpecker/push/deploy Pipeline was successfulDetails
Basically it's a whole rewrite of the README \^_^
I tend to be verbose but tried to make it simple, change suggestions welcome of course :P
So it's probably easier to review by looking at the new file rather than the diff.
---
close#136
Co-authored-by: fr33domlover <fr33domlover@riseup.net>
Co-authored-by: 6543 <6543@noreply.codeberg.org>
Co-authored-by: 6543 <6543@obermui.de>
Reviewed-on: #146
Reviewed-by: 6543 <6543@noreply.codeberg.org>
Reviewed-by: Ta180m <ta180m@noreply.codeberg.org>
Co-authored-by: fr33domlover <fr33domlover@noreply.codeberg.org>
Co-committed-by: fr33domlover <fr33domlover@noreply.codeberg.org>
ci/woodpecker/push/deploy Pipeline was successfulDetails
This PR aims to resolve the chief complaint in #142 (dark mode being implemented by rendering an entirely duplicate dark mode copy of the sites pages).
This makes the following fixes:
- replaces the "two websites" model with a few lines of javascript that will preserve the theme-toggling functionality of the page. This also simplifies the build script somewhat.
- remove the default theme value for the `<html>` tag so the users browser preferences are respected on the first page load
- add a couple lines of JS to ensure that the theme button is set correctly on first load based the users theme preferences.
Co-authored-by: Adrian Edwards <17362949+MoralCode@users.noreply.github.com>
Co-authored-by: Caesar Schinas <caesar@caesarschinas.com>
Reviewed-on: #151
Reviewed-by: 6543 <6543@noreply.codeberg.org>
Co-authored-by: MoralCode <moralcode@noreply.codeberg.org>
Co-committed-by: MoralCode <moralcode@noreply.codeberg.org>
ci/woodpecker/push/deploy Pipeline was successfulDetails
It is the inverse of the existing 'forks' property.
Co-authored-by: Valentin Lorentz <vlorentz@softwareheritage.org>
Reviewed-on: #134
Reviewed-by: Ta180m <ta180m@noreply.codeberg.org>
Reviewed-by: 6543 <6543@noreply.codeberg.org>
Reviewed-by: Aravinth Manivannan <realaravinth@noreply.codeberg.org>
Co-authored-by: Val Lorentz <_zn3val@noreply.codeberg.org>
Co-committed-by: Val Lorentz <_zn3val@noreply.codeberg.org>
ci/woodpecker/push/deploy Pipeline was successfulDetails
"... `vocabulary/` folder looks important but it's outdated and everything in it is either already in the spec or in issues. It was created very early, ... . It's not needed anymore and probably would just confuse people who find it ..."
So remove it.
Co-authored-by: 6543 <6543@obermui.de>
Reviewed-on: #138
Reviewed-by: fr33domlover <fr33domlover@noreply.codeberg.org>
Reviewed-by: Ta180m <ta180m@noreply.codeberg.org>
Pere Lev
Anthony Wang
Sertonix
Val Lorentz
bill auger
MoralCode
6543
Caesar Schinas