GuildPass is an open-source project built around collaboration, technical quality, and respectful participation.
This Code of Conduct applies to contributors, maintainers, reviewers, community members, and anyone participating in GuildPass project spaces.
It applies across:
- GitHub issues;
- pull requests;
- discussions;
- reviews;
- community channels;
- project events;
- contributor programmes;
- other spaces where someone is representing GuildPass or Adamantine Guild.
We expect participants to:
- communicate respectfully;
- focus feedback on the work, not the person;
- assume good faith while still questioning technical decisions when needed;
- explain disagreements clearly;
- give contributors room to learn;
- accept constructive review;
- avoid disruptive or hostile behaviour;
- respect project boundaries and maintainer decisions;
- keep technical discussions relevant to the issue or pull request.
GuildPass is a technical project.
Contributors are encouraged to:
- question assumptions;
- challenge architecture;
- point out bugs;
- raise security concerns;
- propose alternative implementations;
- disagree with maintainers when there is a clear technical reason.
Disagreement itself is not a problem.
The standard is how disagreement is expressed.
Good technical disagreement should be:
- specific;
- evidence-based;
- focused on implementation;
- open to revision;
- respectful.
For example:
This implementation may produce a race condition when two requests acquire the same key concurrently. Could we make acquisition atomic instead?
is useful.
Personal attacks or dismissive comments are not.
Code review is part of the contribution process.
Reviewers should:
- explain why a change is requested;
- distinguish required changes from optional suggestions;
- avoid vague feedback such as "this is bad" or "rewrite this";
- recognise when an implementation satisfies the issue even if it differs from their preferred approach;
- avoid moving the goalposts after a contributor has met the acceptance criteria;
- keep unrelated changes out of the review where practical.
Contributors should:
- respond to review comments professionally;
- ask questions when feedback is unclear;
- avoid resolving substantive discussions without addressing them;
- explain deliberate trade-offs;
- update tests when behaviour changes.
Campaign issues are designed to be specific and independently implementable.
Contributors should avoid:
- taking over another contributor's active issue without coordination;
- expanding an issue far beyond its acceptance criteria;
- creating hidden dependencies on unmerged work;
- bundling unrelated refactors into a feature PR;
- pressuring maintainers to merge incomplete work.
If a separate problem is discovered, raise it separately.
Do not:
- copy another contributor's implementation and present it as your own;
- intentionally overwrite active work without coordination;
- claim credit for work you did not perform;
- use automated or generated contributions without understanding and validating them;
- submit large amounts of low-quality code solely to maximise contribution count.
Contributions are evaluated on quality and correctness, not volume.
AI-assisted development is allowed unless a specific task states otherwise.
Contributors remain responsible for:
- understanding submitted code;
- verifying correctness;
- testing the implementation;
- checking security implications;
- responding to review questions;
- ensuring generated code does not violate licences or project standards.
Submitting generated code without understanding it is not considered an acceptable substitute for engineering judgement.
Security issues should be handled responsibly.
Do not:
- disclose vulnerabilities publicly before maintainers have had a reasonable opportunity to investigate;
- exploit vulnerabilities against real users;
- access systems or data without authorisation;
- publish credentials, private keys, or sensitive information;
- perform destructive testing against project infrastructure.
Follow SECURITY.md for vulnerability reporting.
The following behaviour is not acceptable:
- harassment;
- threats;
- intimidation;
- discrimination;
- personal insults;
- deliberate humiliation;
- repeated hostile communication;
- sexual harassment;
- stalking;
- doxxing;
- publishing another person's private information without permission;
- deliberately disruptive behaviour;
- spam;
- malicious code submissions;
- knowingly misleading maintainers or contributors;
- repeated attempts to bypass contribution or review requirements.
GuildPass does not tolerate harassment or discrimination based on characteristics including:
- age;
- disability;
- ethnicity;
- gender;
- gender identity;
- nationality;
- race;
- religion;
- sex;
- sexual orientation;
- socioeconomic background;
- technical experience level.
People should be able to participate without being targeted for who they are.
Maintainers are responsible for applying this Code of Conduct consistently.
Maintainers may:
- edit or remove inappropriate comments;
- close disruptive discussions;
- reject abusive pull requests;
- restrict participation;
- temporarily or permanently ban participants from project spaces.
Enforcement decisions should consider:
- severity;
- intent;
- impact;
- whether behaviour is repeated;
- previous warnings;
- risk to other participants or the project.
For minor or isolated inappropriate behaviour, a maintainer may request that the participant correct the behaviour.
Examples:
- unnecessarily hostile wording;
- off-topic disruption;
- dismissive review comments.
Expected outcome:
The participant acknowledges the issue and changes their behaviour.
For repeated or more serious behaviour, a formal warning may be issued.
The warning may include:
- the behaviour that must stop;
- expected future conduct;
- consequences of further violations.
A participant may temporarily lose the ability to interact with project spaces.
This may be appropriate for:
- repeated hostile behaviour;
- persistent disruption;
- ignoring maintainer warnings.
A participant may be permanently removed from GuildPass project spaces for severe or repeated violations.
Examples may include:
- threats;
- targeted harassment;
- doxxing;
- malicious code submissions;
- deliberate exploitation of users;
- repeated serious violations after warnings.
If you experience or observe behaviour that violates this Code of Conduct, report it privately to the maintainers.
When reporting, include where possible:
- what happened;
- where it happened;
- when it happened;
- relevant links or screenshots;
- who was involved;
- whether the behaviour is ongoing.
Do not escalate interpersonal disputes publicly when a private report is more appropriate.
Reports involving conduct issues should be handled with discretion.
Maintainers should avoid disclosing the identity of a reporter unnecessarily.
However, complete confidentiality cannot always be guaranteed, especially when investigation or legal obligations require disclosure.
Behaviour outside official GuildPass spaces may still be considered when it directly affects:
- contributor safety;
- project integrity;
- harassment of project participants;
- credible threats;
- someone's ability to participate in the project.
Not every mistake is misconduct.
People can:
- misunderstand tone;
- make technical errors;
- phrase feedback poorly;
- disagree strongly.
The goal of this Code of Conduct is not to punish ordinary mistakes.
What matters is whether participants respond constructively when concerns are raised.
GuildPass aims to maintain a contributor environment based on:
- technical rigor;
- openness;
- accountability;
- respectful disagreement;
- security awareness;
- clear ownership of work;
- high-quality contributions.
A healthy open-source project should be both technically demanding and safe to participate in.
By participating in GuildPass project spaces, you agree to follow this Code of Conduct.