Anything else in the game design doc (on Notion) can also be carried over as the Learning team sees fit, just gimme a heads up. Here’s the full markdown export for it: https://s3.us-west-2.amazonaws.com/temporary.notion-static.com/Export-962578f5-0f0b-4074-b06f-5acba9ddb45e.zip?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAT73L2G45O3KS52Y5%2F20211107%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-Date=20211107T223427Z&X-Amz-Expires=604800&X-Amz-Signature=d4f3ba8c5a8a03b055056dba97771549d90101aa66078815e4aafd4d39fae686&X-Amz-SignedHeaders=host&response-content-disposition=attachment%3B%20filename%20%3D%22Export-962578f5-0f0b-4074-b06f-5acba9ddb45e.zip%22

That link might not work. I’ll need my laptop tomorrow to upload this zip then. Dunno if non-admins can download it on notion, but maybe that’s possible.

It works, I downloaded it

Is there something along the lines of a Rust primer?

@User this is where I started, years ago: https://doc.rust-lang.org/stable/book/

Can we rename

fishfight/FishFight/tree/main/book

to

/learn

?

Also, the licenses in

/docs

should just be moved into root, and the folder deleted.

just a thought: I think it should be its own repo. Will be much easier and less intimidating for non-coders to contribute, when they don't have to interact with the main repo and any fud dealing with that might lead to.

the book, I mean

if we want it in the main repo, too, we can do it as a submodule

I'm certainly open to that. Would love to hear what @User and @User think about it. To me though, docs are so central to the game development experience that it makes more sense to keep them together with the game core.

yeah, I am trying to make all my new additions docs.rs ready. I think that (API docs) is what fits best for that. I might be wrong but I don't think many will interact with the book in its markdown state. Most of the reading will probably be of the web version

dunno if you can extract the rust.rs docs but, at least in my case, I very rarely use the docs included in repos, in stead opting for online API documentation or book pages, similar to ours, in the case of the various Rust books

but it can be added as a submodule

git submodule, that is, if we create a separate repo

but the authors should decide this, of course

At least from my end it's not really about the common git repo, but more about the common Issues space on GitHub.

true, should be a way to link those, across repos in the same org, for example

https://fishfight.github.io/FishFight/contributing.html this should be another one of those proxy pages, because like CoC it gets special treatment on GitHub if it lives in root:

I've thought a little about moving the book into its own repo. It really depends how extensive we want the book content to be. I think the biggest reasons for doing this would be: 1. Separation of concerns: CI jobs, project tracking board/milestones, branches are specifically for book dev (i.e:

gh-pages

branch). 2. Less "bloat" when cloning the repo I think the first reason is less of a concern since we don't have many people working on the book atm. The second one might be bigger as we continue to add images to the book, but again we're not too big so perhaps not worth losing sleep over right now.

I'm not sure if any of that matters to a new contributor though

ah, good point about the images. That on its own could eventually reach a scale that merits separation.

would stuff like the proxy pages we're doing work across repos though?

But I can see cloning an entire repo that includes source code overwhelming to someone who is just starting out and they're just interested in writing gameply/editor docs for Fish Fight. (i.e: what the heck is cargo, Rust, mdBook???)

That one we'll have to investigate and I think would be one of the blockers for moving the book to its own repo

Of course we could just copy paste the md files for those into the separate repo, but then maintaining a consistent version could be a bit annoying

yeh it can help a bit. But speaking as a fairly low-tech person in the context of gamedev (alongside many artists, designers, composers etc.) I don't think it makes a big difference. If you understand the basics of GitHub then the number of folders isn't gonna matter much.

it's easy enough to say: You only need to concern yourself with this folder right here: ..

very true!

Contributing page