Quirk Wiki #22

New Issue

MichaelYick · 2021-06-15T10:57:46Z

MichaelYick commented

2021-06-15 10:57:46 +00:00

Someone suggested listing some development quirks and tips for people coming on board. I think that'd be a great use of our wiki so it'd be nice for some good documentation to go into there (along with internal documentation in the scripts)

MichaelYick added the

enhancement

Low Priority

labels 2021-06-15 10:57:46 +00:00

dagoddamnlazysnake commented

2021-06-15 15:31:23 +00:00

Probably the same thing, but a code guide would be nice too. I'm sure that there are conventions in a year's (or more?) work. Do's and don't's kinda deal.

I would personally find it useful, as half the time I'm worried that my naming or coding standards are off-brand after years of enterpriseify tier work.

Probably the same thing, but a code guide would be nice too. I'm sure that there are conventions in a year's (or more?) work. Do's and don't's kinda deal. I would personally find it useful, as half the time I'm worried that my naming or coding standards are off-brand after years of enterpriseify tier work.

coolestskinnieinthejungle commented

2021-06-15 16:19:11 +00:00

hard agree - getting tribal wisdom thus far written down in a specific place will be a huge thing as more contributers hop on + code base grows.

i'll jot some personal thoughts down i've had insofar and attach them as a markdown doc to this issue in a bit

hard agree - getting tribal wisdom thus far written down in a specific place will be a huge thing as more contributers hop on + code base grows. i'll jot some personal thoughts down i've had insofar and attach them as a markdown doc to this issue in a bit

Ghost commented

2021-06-15 20:32:30 +00:00

Would definitely appreciate this.

MichaelYick commented

2021-06-15 23:24:38 +00:00

What are the major areas that need documenation, obviously the script file and the boilerplate monstrosity that was at the beginning of it. Screens seems like its important too. I'm so used to working on this project I don't even know how my coding quirks differ from the norm anymore lol.

MichaelYick referenced this issue

2021-06-15 23:25:41 +00:00

Lint errors in script #23

coolestskinnieinthejungle commented

2021-06-15 23:40:44 +00:00

here were some initial thoughts i had bounced around - by no means is this finished or even close to a rough draft.

i envision the guidelines + wiki to be democratic in creation - want to have law&order while still fostering freedom. and no CoCshittery

~

ideally i think the most important things we can document would be summarized in three points

project scope stuff - our personal code & syntax quirks, supplemental resource to help devwork related to snootgame specifically like (story) script, etc
existing linked renpy documentation AS IT RELATES TO SNOOTGAME. as more people come aboard that may have dev experience but not renpy experience, having redirects to certain documentation could prove useful. i.e. references to things like https://www.renpy.org/doc/html/python.html
tribal wisdom + ettiquette shit - don't come here pushing a "fixed" bug to master repo/master branch, make a fork, branch whatever the hell you need to, and when your done merge it to your own master and create a pull request to the master repo/current patch branch.

here were some initial thoughts i had bounced around - ***by no means is this finished or even close to a rough draft.*** i envision the guidelines + wiki to be democratic in creation - want to have law&order while still fostering freedom. and no CoCshittery ~ ideally i think the most important things we can document would be summarized in three points * project scope stuff - our personal code & syntax quirks, supplemental resource to help devwork related to snootgame specifically like (story) script, etc * existing linked renpy documentation AS IT RELATES TO SNOOTGAME. as more people come aboard that may have dev experience but not renpy experience, having redirects to certain documentation could prove useful. i.e. references to things like https://www.renpy.org/doc/html/python.html * tribal wisdom + ettiquette shit - don't come here pushing a "fixed" bug to master repo/master branch, make a fork, branch whatever the hell you need to, and when your done merge it to your own master and create a pull request to the master repo/current patch branch.

coolestskinnieinthejungle commented

2021-06-15 23:42:42 +00:00

sorry apparently can't upload .md files so i made it a .txt for now

sorry apparently can't upload `.md` files so i made it a `.txt` for now

SnootWIki.txt

3.1 KiB

MichaelYick commented

2021-06-15 23:49:48 +00:00

since some people have been weary about ettiquate, I went ahead and wrote some ettiquate for dealing with issues and communicating in particular. It's a bit wordy, but pretty detailed and sane. Review, add, and subtract when you can.
https://git.snootgame.xyz/Cavemanon/SnootGame/wiki/Ettiqute

since some people have been weary about ettiquate, I went ahead and wrote some ettiquate for dealing with issues and communicating in particular. It's a bit wordy, but pretty detailed and sane. Review, add, and subtract when you can. https://git.snootgame.xyz/Cavemanon/SnootGame/wiki/Ettiqute

MichaelYick commented

2021-06-15 23:57:56 +00:00

Code Requirements is also up now https://git.snootgame.xyz/Cavemanon/SnootGame/wiki/Code-Requirements

Ghost commented

2021-06-16 04:58:19 +00:00

Related. Lot's of people seem to be working out of their own forks instead of branches. Do you have a preference? I'm entirely used to working with the branch setup.

MichaelYick commented

2021-06-16 08:55:06 +00:00

Principle of least privilege dictates forks > branches for working. Best to work via forks rather than branches as branches would require commit access for people. I rather not have to give commit access to anyone in everyone incase someone's account gets cracked into, someone makes a mistake, or someone decides to go rogue. Its purely a security thing and, like many practices, shoudln't be taken as a personal slight. Forks and PRs also allow code to be more easily vetted by contributors.