! Clearer contributing guide
This should make it easier to understand how to contribute effectively as well as what kind contributions are most needed right now
This commit is contained in:
parent
1edab53778
commit
37c9b88196
@ -1,30 +1,56 @@
|
|||||||
# Contributing to the project
|
# Contributing to the project
|
||||||
|
|
||||||
* Writing chat clients
|
Check the [roadmap](/roadmap.md) to see what specifically is being worked on and what could use more help.
|
||||||
|
|
||||||
I know not everyone wants an electron based client because it's naturally really bloated. But the normans want something that _just werks_ so electron is a good way of doing that.
|
## Languages/Tech Stack - Rust/Python/Bash/Javascript/HTML/CSS
|
||||||
|
|
||||||
The API is dead simple however so it shouldn't be too bad to write a simple client that sends a couple of requests every so often.
|
Here's a quick run down of the tech-stack:
|
||||||
|
|
||||||
If you choose to write a client and want people to know about it I can include a link to the project here/on the wiki.
|
* json-api: Written with Rust
|
||||||
|
|
||||||
* Testing
|
* json-api/client-tests/: A python based mock client used to verify the behavior of the REST API
|
||||||
|
|
||||||
Currently API testing is done with a phony client written in python(client-tests/client.py) and some rust tests.
|
* rtc-server/: A web socket server with NodeJS
|
||||||
|
|
||||||
Anything from a simple `GET /some-route` + response check to a testing pipeline thing is appreciated.
|
This optional feature provides real time chatting. Future plans also include voice chat as an additional feature.
|
||||||
Since testing doesn't really affect users, as long as the test is correct and covers new ground it's welcome.
|
|
||||||
|
|
||||||
* Languages - Rust/Python/Bash/Javascript/HTML/CSS
|
* freechat-client/: Electron based client _(that is always behind the backend'd development)_
|
||||||
|
|
||||||
The API service is written in rust. Uses mysql-async wrapped in a small library for abstracting away database code from the "business logic"
|
The whole point of this client is to give regular users something that works on every platform.
|
||||||
|
|
||||||
* Scripting
|
* tui/: Rust based text client _(Currently very far behind backend's development)_
|
||||||
|
|
||||||
Build scripts are literally just Bash scripts so if a script looks like it can be used to automate some boring process then that could be a great way to contribute.
|
The purpose with this tui is to be a keyboard driven program to be used in a terminal.
|
||||||
|
|
||||||
* Electron Client
|
* invites-manager/: Python script that acts as a simple cron job, removing old/stale invites
|
||||||
|
|
||||||
The electron client is built with NodeJS + Bootstrap(nothing else).
|
* chan-like/: Similar to the invites-manager but written in Rust, made to remove old messages similar to how a modern image board removes old threads
|
||||||
Adding libraries to the client requires _very_ good reason IMO.
|
|
||||||
I know Electron is a whale so I want to do everything in my power to make sure it doesn't weigh much more.
|
In part the purpose with this is to keep the amount of data stored in the database to a minimum but also because not everyone
|
||||||
|
is going to want messages to persist forever. This feature is optional.
|
||||||
|
|
||||||
|
## Writing chat clients
|
||||||
|
|
||||||
|
For a reference to the Freechat API check the [wiki](https://freechat.shockrah.xyz/).
|
||||||
|
|
||||||
|
The REST API aims to be as stable as possible in behavior as well as straight forward as possible.
|
||||||
|
This should hopefully make it easier to develop simple client programs.
|
||||||
|
|
||||||
|
The electron based client and the tui client are meant to be the two officially supported client programs right now however they are not in usable states at the moment.
|
||||||
|
|
||||||
|
## Submitting Patches
|
||||||
|
|
||||||
|
The preferred method is through merge requests, however, for some special cases you may send me patch files at the email listed [here.](https://shockrah.xyz/links.html)
|
||||||
|
Individual changes in a given patch should be noted with the following things:
|
||||||
|
|
||||||
|
* A short one line sumary prefixed with a `*`, `+`, `-`, `!`
|
||||||
|
|
||||||
|
* `*` Marks a 1 to 1 change
|
||||||
|
* `+` Marks some addition
|
||||||
|
* `-` Marks some removal
|
||||||
|
* `!` Marks an important note about one of the above, similar to a warning regarding a patch note
|
||||||
|
|
||||||
|
* (If applicable) A more detailed summary/explanation regarding the patch
|
||||||
|
|
||||||
|
This is where context can be given regarding why this patch is being applied and what details are important to quickly understanding the patch details.
|
||||||
|
**NOTE**: if the patch is really tiny (a simple typo fix for instance) this part may not be required.
|
||||||
|
Loading…
Reference in New Issue
Block a user