Closed cosmopetrich closed 1 hour ago
Steps to build the mod should go into the wiki/documentation probably. Maybe the into GitHub wiki or something like that.
Maybe. Wikis are nice when there's a reasonable amount of information to collate. They seem a little detrimental for something that's a "single page" compared to a block or two in the README.md
or another markdown file in the main repo. Information in the main repo is right there when someone clones it, and the same workflows which are used for the codebase can apply to the file.
Edit: To be clear, definitely a good suggestion and a solid option if there's more stuff to put there.
Could put the JSON structures of the endpoint into there too
i am open to adding this information to either github wiki or in the docs, but if we do that, we should include atleast a link into the README.md. The README.md is the first thing you read and you should read about the "contribution guide". Many projects include a contributing.md in the .github directory with a guide, that could be a thing (just as an idea),
I think we should avoid blowing out the scope of this issue, which is just "hey maybe it's possible to save folks who want to contribute a few minutes when they're building it."
Discussion of moving the docs from adoc to wiki markdown etc are probably best had elsewhere.
Documentation hosting is provided by the Vilsol and Night from the modding discord, and my docs are pulled by: https://github.com/satisfactorymodding/Documentation
I hope that helps. Mine is more of a subpage? that is pulled by the main docs site.
It is probably best to add CONTRIBUTING.md
as a separate file, with steps on how to build the project and such. @porisius would need to make the contents of it tho since he knows how to develop and work with his mod 😅
Unless anyone else wants to make a pr to the dev branch.
Request for review https://github.com/porisius/FicsitRemoteMonitoring/commit/941dc104c6bf6ff81ba1debc9209a907dbcfa0e6
I am likely going to end up rebasing dev onto main. I am not sure if that is the best idea, but I am open for suggestions.
If we're all already building and using dev
as the main branch, resetting main
to dev
may be the less disruptive option at this point
The end-goal is to have main be the branch that the GHA compiles and uploads the mod to ficsit.app
You know, when I can get to it.
Since there's no push/update auto-actions happening on main currently it's probably fine to rebase main onto dev until those features are added.
PS contributing guide seciton looks great 👍
Th3Fanbus (Rex) on the Modding Discord made a comment that has me thinking, and I should have asked in a more open channel so a more open discussion could have been made. I probably didn't want for it to get lost.
When contributing to this project, you must agree that you have authored 100% of the content I feel that's overly strict, consider something like this instead? https://doc.coreboot.org/contributing/gerrit_guidelines.html#sign-off-procedure
Thoughts? I can see the "CYA" aspect, but I don't want to be too strict or too off-putting that someone who was what I was (i.e. in-experienced and overly eager) doesn't want to contribute.
that's fine and not a big ask - for anyone who hasn't signed off there are bots that can reply stating that we require signoff on all commits with instructions on how to do so. It's not a huge hurdle for a good legal CYA
Agree that the contribution docs look good. No objection to a sign-off either.
Thanks to Toast, main and dev are now sync'd
103 was helpfully opened by @derpierre65 to add notes on the extra steps required to build FRM from source. The other step I'm aware of is to build off the
dev
branch rather thanmain
. While it would be easy to add that to the readme as well, I wonder if this might be a good time to do something withmain
?Based on my experience building the project, the
main
branch is currently broken. It might be nice to have the default branch in a usable state, though. It's what people will go to automatically, is the default target for PRs, etc. One approach might just be to mergedev
intomain
and treat it the waydev
is treated now. Though there are obviously different branching schemes too.If it's best just to keep things as-is then I'm happy to add a note to the readme.