search

gbadev-org / gbadoc

Community initiated GBA Technical documentation effort
http://gbadev-org.github.io/gbadoc/
Creative Commons Zero v1.0 Universal
46 stars 7 forks source link

github repo settings #5

Closed Lokathor closed 2 years ago

Lokathor commented 3 years ago

We should disable the Wiki tab. Content shouldn't get into the repo wiki, it should be going into the repo files which are published to github pages. Having the wiki enabled can give people the wrong idea.

We should also consider enabling the Discussions tab. We have the discord, but that's only good for short term discussions. For longer term questions, it's nice to have a place to post about something and people potentially can see it days or weeks from now.

quentin-dev commented 3 years ago

For longer term questions, it's nice to have a place to post about something and people potentially can see it days or weeks from now.

How does this differ from opening an issue / RFC to discuss it?

LunarLambda commented 3 years ago

I'd say RFCs are for discussing a very particular issue with the goal of finding a definite answer, and we were thinking of only keeping RFCs open for around a week generally

Discussions are much less restrictive in what can be brought up and when

avivace commented 3 years ago

We should disable the Wiki tab. Content shouldn't get into the repo wiki, it should be going into the repo files which are published to github pages. Having the wiki enabled can give people the wrong idea.

We should also consider enabling the Discussions tab. We have the discord, but that's only good for short term discussions. For longer term questions, it's nice to have a place to post about something and people potentially can see it days or weeks from now.

I'd keep the Wiki tab for some technical documentation (e.g. how to deploy) or some general rules (e.g. rules on units and acronyms) on how to write for gbadoc. Everything that needs fast/frequent iterations could go in there before getting committed in the main repository (so we don't fill the git history). Take a look at Pan Docs Wiki, we do something similar over there

Lokathor commented 3 years ago

I think that's important to write down, but it should still be in the repository content itself.

in terms of history, we can always do squash merges when finalizing a PR.

avivace commented 2 years ago

I think that's important to write down, but it should still be in the repository content itself.

in terms of history, we can always do squash merges when finalizing a PR.

I agree on this. I disabled the Wiki tab and enabled Discussions