Skip to content

Document our development and contributing guide #82

@BigLep

Description

@BigLep

Done Criteria

There is an easily discoverable document that bootstraps someone on contributing, sets expectations of contributors/developers, and answers related frequently asked questions.

Why Important

Having a community of contributors is a key success criteria for Helia. I hypothesize that documentation here helps makes contributing more approachable/self-service.

Notes

I know we link to https://github.com/ipfs/community/blob/master/CONTRIBUTING_JS.md. It looks like that has some older stuff. I think we either need to update that doc inline, copy it and make updates, or create an addendum with Helia specifics and then link to https://github.com/ipfs/community/blob/master/CONTRIBUTING_JS.md. I expect we want our own place to add copy just so there is no friction to be documenting Helia-related things. I worry folks would shy away from touching https://github.com/ipfs/community/blob/master/CONTRIBUTING_JS.md because they don't know whereall it's linked from or because Helia specifics aren't relevant there.

Items that would want to see included:

  • Link to the release process/philosophy (Document the release process / expectations #81)
  • Set clear expectations on how PRs are to be titled/written.
  • Where can someone show up to engage with other contributors (e.g., chat, triage)
  • Where the inprogress and ondeck work is tracked (presumably linking to a Helia project board)
  • Expectation that PRs are linked to issues that provide rationale and justification for the work. (It should be clear to a reviewer "why are we doing this")
  • Include some of the verbiage that is copy/pasted various places like "Please be aware that all interactions related to this repo are subject to the IPFS Code of Conduct" or "Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions." We can then remove that copy/pated text.
  • How someone become a maintainer? (We can say that this process needs to be fully determined, but starts with showing making contributions and demonstrates good judgment)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions