{{ message }}
Repository navigation
Extend contributors guide #4485
Description
Following #4200
The project could include further documentation: https://github.com/sindresorhus/refined-github/blob/main/collaborators.md
What else should we include? This is different from the generic contributors guide, which is more of an entry point and doesn't need to include a lot of details about the codebase.
This file could include instructions on how the codebase is organized and nitpicks to ensure consistency when reviewing, which currently are "unwritten rules" and lints like:
- how to cache API calls correctly
- sort imports a certain way
- when to use elementReady and what it is
- keep in mind GHE when using absolute URLs
- use
// TODO[2021-10-01]: GHE #1234comments to remind us to drop old code after a year- GHE support policy: I suggest dropping code a year after it has changed on GitHub.com
- GHE code: preserve unchanged instead of mixing it with new code, unless it's a single selector change. When dropping it, it'll be as easy as deleting whole lines instead of untangling it from live code.
Also in the contributors guide we could add:
- general code instructions (e.g. use this listener instead of that)
- how to reverse engineer GitHub
Activity
kidonng commentedon Jul 7, 2022
Now this issue is regarding the contributors, but what I had asked in #4288 (comment) is more user-facing, about feature caveats and helpful info like #5501. They are scattered around thousands of issues, and we frequently need to dig around to provide these for users. Wouldn't it be optimal if we can enable wiki in this repo so we have a central place to store these knowledge instead of opening obscure aggregation issues like #2960?
fregante commentedon Jul 7, 2022
Good idea, let’s move that content to the wiki. Even the contributing guide can be moved to the wiki to facilitate contributions.
Keep in mind however that the vast majority of the knowledge will continue to be lost in the conversations and commits, because nobody will spend time to move it out after a PR has been merged.
It would be interesting to create
forked-to.mdto preserve as much information as possible and explain them a little more, but most of these files will just be “feature name, one line description, screenshot”. Does anyone have time to describe the features further + move this information out of the readme + create a workflow to further index these files?Probably not 😂 it’s best to just move those 3/4 issues into the wiki.
As for the CSS stuff, I would not spend time on that at all. If enough people complain, we just make the feature disableable, it makes no sense to maintain undo styles. Our intention is to just avoid having to move every single CSS change to a JavaScript file.
kidonng commentedon Jul 7, 2022
I will spend time maintaining the wiki 😉 I've complained lack of detailed docs a few times already.
Writing reverts still takes time and effort, however simple it is. Put them somewhere easy to find save both users and our time.
fregante commentedon Jul 8, 2022
We can also move this issue to the wiki:
And add more links to core test URLs like
kidonng commentedon Jul 8, 2022
fregante commentedon Jul 8, 2022