I would like for there to be a way to integrate "community health files" into the appview, similar to other git forges.
Proposed changes#
This goes in the same line of project management UX in another issue I wrote before. Ideally, I should be able to:
- Define a markdown file for an issue template/pull request template somewhere in the repository (e.g in
.tangled/,docs/, or root directory) - When I click the new issue button:
- If the repository has no issue templates, default to the regular form
- If it does, then I can choose between different issue templates
- When I click the new pull request button:
- If there is a template, automatically prefill the form
- See links to contribution guide when I'm at the issue creation form (issues/new) + pull request creation form (pulls/new). This text can be a description to the body textarea input
- This text could be as simple as like "Before submitting, be sure to check the contribution guide." (text can totally be workshopped)
- GitHub uses: "Remember, contributions to this repository should follow its contributing guidelines and code of conduct."
Notes#
GitHub uses these file patterns:
- Issue template:
.github/ISSUE_TEMPLATE/*.md - PR template:
/pull_request_template.md,{.github,docs}/PULL_REQUEST_TEMPLATE/*.md - Template chooser:
.github/ISSUE_TEMPLATE/config.yml - Contribution guide:
/CONTRIBUTING.md,{.github,docs}/CONTRIBUTING.md
Following same/similar file patterns also makes migrating repositories from another git forge to tangled more seamless. GitLab has slightly different patterns, hough I mentioned GitHub's here since it's the most popular one. Ideally the user doesn't have to move the files anywhere if it's already in the root or docs/ dir, OR they can just rename .github/ to .tangled/
I don't actually think it's that common to have multiple PR templates for a repo though, so we could start with allowing just 1 PR template per repo.
Proposed implementation#
- Choosing an issue template should be some URL query parameter, like
issues/new?template=<template-name> - Needs storing the data of community health files somewhere. I'm assuming it would make sense to associate community health files of a repository at an ATProto lexicon level?
good idea! Ideally I want to have more general spec for meta files instead of
.tangledlike I proposed from here, but appview-wise, this can be a good start.We integrate git objects to atproto with knot. For example, workflows are defined in
.tangled/workflows/*.ymland parsed dynamically on demand. We can have some cache layer with git hash to prevent constant fetching.My suggestion is to have knot xrpc method to serve the parsed community health files. Ideally this should be done automatically from appview and shouldn't depend on individual knots, but that's how most things work right now.