AkkomaGang/akkoma
AkkomaGang/akkoma
17
70
Fork 115
Code Issues 146 Pull requests 15 Projects 2 Releases 23 Packages Wiki Activity

Create contributor guidelines #1100

Open
floatingghost wants to merge 2 commits from contributing into develop
pull from: contributing
merge into: AkkomaGang:develop
Conversation 2 Commits 2 Files changed 2 +23
floatingghost commented 2026-04-01 09:29:21 +00:00
Owner
Copy link

A basic first policy - i think this covers what we'd want to cover

that is mostly that we need to be certain of the provenance and correctness of PRs sent to us

A basic first policy - i think this covers what we'd want to cover that is mostly that we need to be certain of the provenance and correctness of PRs sent to us
👍 1
i mixed up the fname
Some checks are pending
ci/woodpecker/pr/test/1 Pipeline is pending approval
Details
ci/woodpecker/pr/test/2 Pipeline is pending approval
Details
d9a255c774
Oneric reviewed 2026-04-02 19:48:09 +00:00
Oneric left a comment
Owner
Copy link

Regarding the AI policy, I think it’s fine.
As with any policy it could ofc be endlessly bikeshed about the right level of verbosity, whether or which motivations to include, potential edge cases etc. But in the end, this is not some stringent, blindly applied law and sensible enforcement is up to maintainers and ultimately the project leader (i.e. you) anyway. (Meaning: it doesn’t need to hold up to malicious by-the-letter interpretations)
Trying to explain the reasoning and focussing on the aspects most directly relevant to Akkoma and the patch submission process itself is one way to go about it and might clear up the intent while if anyone tries to weasle another interpretation out of it we can still reject it anyway.

However, since the file is CONTRIBUTING.md and pointed at for any kind of contribution in our readme, I think it should include a bit more.
For one, contributors are ofc also expected to follow our code of conduct to keep the community environment welcoming. Meaning there should be a pointer to CODE_OF_CONDUCT.md.
Furthermore we already have (though possibly somewhat dated) “getting started” instructions for new contributors in docs/docs/development/index.md and other doc files it points at. (It currently mentions writing tests, but not explicitly encourages running the full test suite on patch sets: It probably should). This too would be good to reference.

Regarding the AI policy, I think it’s fine. As with any policy it could ofc be endlessly bikeshed about the right level of verbosity, whether or which motivations to include, potential edge cases etc. But in the end, this is not some stringent, blindly applied law and sensible enforcement is up to maintainers and ultimately the project leader *(i.e. you)* anyway. *(Meaning: it doesn’t need to hold up to malicious by-the-letter interpretations)* Trying to explain the reasoning and focussing on the aspects most directly relevant to Akkoma and the patch submission process itself is one way to go about it and might clear up the intent while if anyone tries to weasle another interpretation out of it we can still reject it anyway. However, since the file is `CONTRIBUTING.md` and pointed at for any kind of contribution in our readme, I think it should include a bit more. For one, contributors are ofc also expected to follow our code of conduct to keep the community environment welcoming. Meaning there should be a pointer to `CODE_OF_CONDUCT.md`. Furthermore we already have (though possibly somewhat dated) “getting started” instructions for new contributors in `docs/docs/development/index.md` and other doc files it points at. *(It currently mentions writing tests, but not explicitly encourages running the full test suite on patch sets: It probably should)*. This too would be good to reference.
Oneric commented 2026-04-02 20:53:11 +00:00
Owner
Copy link

oh also: maybe it be good to point out in the doc page (or CONTRIBUTING.md directly?), that large changes (e.g. affecting the db scheme more significantly than a simple new column; or similarly the processing pipeline; etc) should best first discuss the approach either in the IRC channel or as an RFC issue to make sure it fits in with current architecture and planned future changes and to avoid unnecessarily wasting work on subpar approaches or in case the feature is not desired at all
(as a side effect, if prospective contributors first explain and reason about the concept (and the "reasoning" isn’t just LLM slop itself), they actually must have put some thought into it)

oh also: maybe it be good to point out in the doc page *(or `CONTRIBUTING.md` directly?)*, that large changes *(e.g. affecting the db scheme more significantly than a simple new column; or similarly the processing pipeline; etc)* should best first discuss the approach either in the IRC channel or as an RFC issue to make sure it fits in with current architecture and planned future changes and to avoid unnecessarily wasting work on subpar approaches or in case the feature is not desired at all *(as a side effect, if prospective contributors first explain and reason about the concept (and the "reasoning" isn’t just LLM slop itself), they actually must have put some thought into it)*
Some checks are pending
ci/woodpecker/pr/test/1 Pipeline is pending approval
Details
ci/woodpecker/pr/test/2 Pipeline is pending approval
Details
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin contributing:contributing
git switch contributing
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
approved, awaiting change

   
broken setup

Issue arose from a misconfiguration by the admin, custom patches, manual db edits or similar

  
bug

Something is not working

  
cannot reproduce

   
configuration

This requires config changes

  
documentation

This is about human-readable docs

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
extremely low priority

   
feature request

Something new?

  
Fix it yourself

Support has been attempted

  
help wanted

Need some help

  
invalid

Something is wrong

  
mastodon_api

   
needs change/feedback

Issue or PR is stalled on response from the author or a third party

  
needs docs

   
needs tests

   
not a bug

   
not our bug

Bug in a dependency of ours (meaning we can't just fix it), or in another AP implementation or client interfacing with Akkoma (which needs to be fixed on their end)

  
planned

   
pleroma_api

   
privacy

   
question

More information is needed

  
static_fe

   
triage

   
wontfix

This won't be fixed

No labels
approved, awaiting change
broken setup
bug
cannot reproduce
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs change/feedback
needs docs
needs tests
not a bug
not our bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
AkkomaGang/akkoma!1100
No description provided.