mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-05-04 18:09:12 +03:00
Patch file for documentation changes #154
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @sparky8251 on GitHub (Dec 27, 2018).
Originally assigned to: @anthonylavado on GitHub.
Here is the gist: https://gist.github.com/sparky8251/47d028ee14f6a00a37ba97fb1264e714
Hopefully a diff is easy enough to merge for you guys.
This diff doesnt really add anything except a few issue tags to the issue guidelines. What it does do is standardize formatting and spacing.
Started all numbered lists with 1 instead of 0, all sub headers are 3 # instead of some being 2 or 4, used * everywhere instead of having a mix of it and -, found and fixed a few typos, etc.
I want to add to the wiki, but that's for later 🙂
@JustAMan commented on GitHub (Dec 28, 2018):
@sparky8251 can you add patched versions of files to the gist? It makes understanding final formatting easier.
@sparky8251 commented on GitHub (Dec 28, 2018):
Done and done. Check the gist link again and it should have all the files as they would appear after patching.
@joshuaboniface commented on GitHub (Dec 30, 2018):
Integrated into the Wiki at https://github.com/jellyfin/jellyfin/wiki/Building-from-Source
@joshuaboniface commented on GitHub (Dec 30, 2018):
A lot of these changes reference lists and such, a few I agree with but I like the
0.style since that auto-increments and avoids messing with numbering. That it starts at 0 instead of 1 is not particularly important IMO.However there are a lot of good suggestions here and I'll keep working through them.
@sparky8251 commented on GitHub (Dec 30, 2018):
Using 1 for everything also auto increments on the Github wiki. Just figured that 1 is more commonly used by non-programmers, the ones that are likely to be contributing documentation edits as one offs and that we should be accessible to.
Especially since the documentation should be standardized with a "wiki style" like the coding style. This was just my attempt at implementing such a thing.