shockrah/freechat
shockrah/freechat
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'master' of gitlab.com:shockrah/freechat

Browse Source
This commit is contained in:
shockrah 2021-06-14 13:10:49 -07:00
commit 1cd2186541
1 changed files with 42 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
contributing.md
View File

@ -1,30 +1,56 @@
# 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.
Since testing doesn't really affect users, as long as the test is correct and covers new ground it's welcome.
This optional feature provides real time chatting. Future plans also include voice chat as an additional feature.
* 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).
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.
* 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
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.