🔨 Update contributors guide and rules

[zach2good]

• [x] I have paid attention to this example and will edit again if need be to not break the formatting, or I will be ignored
• [x] I have searched existing issues to see if the issue has already been opened, and I have checked the commit log to see if the issue has been resolved since my server was last updated
• [x] I have read and understood the Contributing Guide

Describe the feature

As with all software projects, docs get outdated and left behind, and rules/requirements change and get added.

We've had an influx of new contributors recently and we could do with clarifying things that we want (and then announcing the new rules very loudly).

• Coding standards need more clarifications and examples, and more tooling to enforce it
• Clarify what's expected from PRs and issues, especially in regards to research, reporting details, clarity/sanity of git commits, names and titles of things etc.
• Clarify who/when a Draft PR is acceptable, we've set a bad example and it's has become a sort of norm when it shouldn't have

(add more suggestions)

[zach2good]

• Our first objective is to be a server emulator for the modern retail version of the game, we have very little interest in implementing or supporting any 'era' version of the game, unless it's as simple as a switch that allows us to swap out some numbers.
• We actively encourage you to keep a retail subscription, to support the game we all love, and allow you to observe it.
• We have no interest in replacing retail, and as such, we won't be implementing (or accepting implementations) for retail's newest tier of content.
• Given these above points, there's fully zero reason to not be able to provide retail captures alongside implementations. A grainy YouTube video, a single 'clopdiea article, a forum post by some nobody from 2006 etc. Are not good enough proofs.
• Leaving extremely simple things as TODO because you don't have a retail capture for them is unacceptable. Get yourself an account and capture it, or ask nicely for someone to do it for you in the captures discord. You can also just brute-force test until you get the results you're looking for a lot of times

[zach2good]

We care more about being an emulation software, not a server platform. We're not interested in providing and maintaining GM tools, auction house automation scripts etc.

[zach2good]

We get many many reports of bugs from altered or very outdated versions of the software. The only sane way for us to triage bugs is to make sure they're reproducible on our latest base branch, so do that

[TeoTwawki]

We care more about being an emulation software, not a server platform. We're not interested in providing and maintaining GM tools, auction house automation scripts etc.

we should have a bit of wiggle room on this: while we may see fit to do something that happens to benefit those things, it's not our main goal here. More of a happy side effect. More may or may not happen in the future but nobody should expect those things as a standard use of our time.

[WinterSolstice8]

perhaps it's time for https://github.com/LandSandBoat/server/wiki/Proof-of-Work

[zach2good]

perhaps it's time for https://github.com/LandSandBoat/server/wiki/Proof-of-Work

Absolutely

[TeoTwawki]

Seconded and thirded. There are a small number of things I wouldn't be as strict on, but 99% of everything should be backed by caps and provably true before reaching a PR.

[TeoTwawki]

• Clarify who/when a Draft PR is acceptable, we've set a bad example and it's has become a sort of norm when it shouldn't have

I think PRs should be mostly DONE before hitting our repo, or it should be a discussion thread instead of a PR. Drafts should be either devs making visibility (example: Zach on Chocolos stuff) -or- a collaborating thing between multiple people for a feature branch (example: garrison)

[zach2good]

Start discouraging the use of many many IDs checked into Lua.

• For mobs and NPCs: look for ways to use zone:queryEntitiesByName('...'), even if the name is a little lame
• For text IDs, use as little as possible, and generate offsets from the nearest point you can (helps the tooling during updates not freak out)

[zach2good]

• Make sure a link to the capture discord is displayed and prominent, and make sure it's obvious that we want things to be built by looking at caps, not by something your cousin's friend who had a relic in 2007 said at a LAN party once while you were drunk.

[TeoTwawki]

1. This project is not anyone's dayjob. While we go through a lot of trouble to keep things as buttoned up as we can, this is not a professional product it is a hobby project and your quality expectations should adjust accordingly.
2. Having opened a pull request doesn't mean you are owed anything
3. Thing_A being wrong doesn't make creating a Thing_B wrong ok.
4. This should not need said but somehow feels like it does lately: we are not required to merge any of the work nor required to merge the whole contents (reference to no.2 and no.3)
5. While the Code of Conduct is intended to cover this, recently displayed attitudes by multiple persons both on and off GitHub indicate the need to reiterate right in the guides that snapping at mouthing off at or slandering devs to users on or off GitHub is not acceptable and repeat offenders WILL be kicked to the curb and given no further assistance.

---

other thoughts:

• Make sure a link to the capture discord is displayed and prominent, and make sure it's obvious that we want things to be built by looking at caps, not by something your cousin's friend who had a relic in 2007 said at a LAN party once while you were drunk.

It's ironic (and very frustrating) that LSB members occasionally gets accused of doing this by people who don't really know what retail actually does when we actually use caps, while we struggle to stave off people trying to bring in wrong things based on what they saw some dude on the internet say without any verification. Even if every single commit linked a live stream I think it'd still happen.

[zach2good]

While the Code of Conduct is intended to cover this, recently displayed attitudes by multiple persons both on and off GitHub indicate the need to reiterate right in the guides that snapping at mouthing off at or slandering devs to users on or off GitHub is not acceptable and repeat offenders WILL be kicked to the curb and given no further assistance.

It has always felt as if the code of conduct is there to protect users/contributors from unfair treatment by us, and we've not done a good job of using it to defend us from toxic users/contributors. I think we should be a lot more active in starting the code of conduct warning process against people who are harassing us because we want good code/proof/sane PR titles/retail accurate changes/no snarky PR titles/not to be treated like shit for being the maintainers of this project etc.

[zach2good]

It benefits us (through bug reports) if:

• Users can get set up quickly and easily
• Users can update and maintain their server easily
• Users get a fast and resource-efficient server that runs on a variety of hardware configurations
• Users are able to host a comparable number of players as retail FFXI can, with a similar gameplay experience
• Users have a suite of options for customisation that don't invalidate bug reports
• Users are empowered to contribute - guided by a high-quality and uniform codebase, clear CI rules, and a wiki of guides and articles

As a small team of volunteers, the only way we find out about bugs is through bug reports. If you don't report it, we'll never know, and we can't fix it.

[zach2good]

I want to get across the point that: If you're running a server and you get a bunch of players, and you customise it and you're having a really good time - that's great - but it's of no value to us if you don't report bugs and innaccuracies and crashes to us

[zach2good]

• Our main goal is to produce an accurate server emulator for the modern retail version of the FFXI.

• When retail FFXI eventually switches off, we will target and support whatever the final client and server version is.

[zach2good]

Using Era Dynamis as an example:

It'd be cool if we had it available as a module, and it was all stable and fast and correct, and nobody had to mess with it unless they wanted to customise it, but if it's anything less than all of those things - we'll be getting bug reports about it and having to maintain it. Which takes time and energy away from "produce an accurate server emulator for the modern retail version of the FFXI"

EDIT: Specifically because its some of the only hugely popular content that was reworked and doesn't bear any resemblance to its original form. I still don't know how similar Dynamis Divergence is, and whether or not a good and full implementation of DynaD could be retooled with modules to provide Era Dynamis?