Add community rules, how-to-ask-report-and-request and hacking pages

[agnostic-apollo]

Pages temporarily viewable at https://github.com/termux/termux-community/blob/site/site/pages/en/index.md

DO NOT MERGE! Termux site changes need to completed first.

I have updated the community rules, especially for hacking exemptions that were raised internally. Let me know what you termux members and moderators think.

Related pull at termux/termux-packages#18887

[sylirre]

Looks good

[truboxl]

I think can add on crypto / mining related stuff that should be prohibited / requests wont be entertained...
Exceptions maybe wallet related...

[TomJo2000]

We'll probably wanna add a

Note

Note section

Important

Important section

or

Caution

Caution section

For a couple languages.
Python, NodeJS and Lua come to mind in particular.

Lua probably just needs a note (or [!TIP]) going over LuaJIT + Neovim as a very common usecase.

Node probably deserves a caution section about NPM self upgrade.

And Python should have a important or caution section about NumPy, and other modules with a lot of native C/Fortran/Rust code.

See: GitHub Flavored Markdown documentation for the alert labels extension.

[sylirre]

@truboxl Mining and making profits using cryptocurrency is out of Termux scope. We would not want to serve such issues, especially when person who submitted such issue knows nothing about mining but watched a scam video on YouTube and now tries to set up a coin faucet click bot for "mining".

Real mining on public blockchain networks using a mobile device isn't possible as ratio (user_hashrate) / (total_network_hasrate) would be exceptionally low. Moreover in the long run this it would be harmful to hardware due to poor heat dissipation.

The software for setting up full blockchain nodes should be acceptable for packaging, although it could be difficult to set up as require hundreds of gigabytes of available storage space (need to download and store lots of data).

[agnostic-apollo]

Thanks @sylirre for the approval. Forgot to add your co-authrored tag, since many parts were based on your wiki and reddit docs. Also added your gem phrase, you probably know which ;)

@truboxl Yeah, mining could be added. I think I should add a Content Not Allowed rule at number 8 and add hacking, mining and other future restrictions there, and can link to dedicated pages if required, like currently being done for hacking. If someone wants to write one for mining and potential impacts on device and its uselessness, that would be helpful. If we reference rules by number, that may be an issue if we change rule numbers later, I guess shouldn't do that. Using single rule for Content Not Allowed would help with not having to create a new rule number for each new restriction.

@TomJo2000 Yeah, it would be great to use that, but docs are currently being written so that they can be viewable locally without an internet connection in the Termux app itself, which uses the Markwon java library, which implements the CommonMark spec. GFM is a strict superset of CommonMark. GitHub pages also uses jekyll-commonmark, which uses commonmarker, and even that only supports few GFM extensions. The jekyll-commonmark-ghpages gem also doesn't use GitHub heading anchors format, it uses kramdown format instead, I need to send pull to get support added in upstream to support GitHub format, as currently, headings are not compatible between normal GitHub viewing, like link above and when done on site. kramdown removes leading no alpha characters and removes whitespace between words completely, instead of replacing them with a dash - like GitHub does, so the heading 1. Follow posting guidelines would be 1-follow-posting-guidelines on GitHub and followpostingguidelines for kramdown. Markwon doesn't support scroll to heading by default, it needs to manually implemented as an addition. Basically I need to maintain compatibility on normal GitHub, GitHub pages for site and Android app, so only features supported on all will be used.

Bold could be used for important stuff, or possibly an icon can be added.

• https://github.com/noties/Markwon
• https://noties.io/Markwon
• https://spec.commonmark.org/0.28/
• https://github.com/gjtorikian/commonmarker/tree/v0.23.4#extensions
• https://github.com/jekyll/jekyll-commonmark
• https://github.com/github/jekyll-commonmark-ghpages
• https://github.com/gettalong/kramdown

For packages related changes, either post them here, or push commits in my pulls or you can send a pull later once my pulls are merged. I don't have time for writing those changes myself, a lot already on my plate in my well.

[truboxl]

Ok I suppose can add a more general Content Not Allowed clause later on. Yep sylirre explained very well and that could be a starting point. I did think of mining as there's quite some users out there have this kind of usecase using Termux but they don't aware or care the inefficiency and damages they can do.

And then there's piracy also which is a very grey area at the moment. But let's think of that for next round.

[TomJo2000]

Ok I suppose can add a more general Content Not Allowed clause later on. Yep sylirre explained very well and that could be a starting point. I did think of mining as there's quite some users out there have this kind of usecase using Termux but they don't aware or care the inefficiency and damages they can do.

And then there's piracy also which is a very grey area at the moment. But let's think of that for next round.

Petition to add "API in a trenchcoat" packages to the exclude list.
AI, I'm vagueing about (commercial, proprietary) AI...
Like OpenAI, or DALLe or whatever, packages that are just a glorified API adapter.

[sylirre]

What concerns do you have about API adapters?

I think they are good to be added if doesn't violate service ToS. Of course multiple clones of the same tool shouldn't be requested. For something that is looking too raw, there is a TUR repository: https://github.com/termux-user-repository/tur

[TomJo2000]

TUR, maybe.
But most of them tend to be written in Python or JS and don't require packaging to work on Termux.

[agnostic-apollo]

AI is going to be part of the future, even if everyone is not too enthusiastic about it and there are legitimate use cases for AI based tools in Termux for general users, and also by commercial companies. There are lot of wrappers or implementing a spec based packages, not just for AI, I don't see anything necessarily wrong with them and they are not for destructive purposes either. The project being well known rule would still apply to any wrapper that is requested to be added that we have for other packages, every willy nilly wrapper shouldn't of course be added. We still package some tools that are based on interpreted languages if useful and worthy enough. Careful selection is the way to go instead of outright exclusion IMO.

[TomJo2000]

Oh I've long since given up on being an AI hater, now I'm just a indigent maintainer dreading having to maintain and support all this AI stuff I have little to no use or interest for.
I'll live, provided I don't end up on GPT-7's hit list.

[Grimler91]

Will go through the text within a day. I suggest we break all the lines to make it easier to review (and and in the future), diff's are hard to look at when lines are long. Will open a PR against the site branch

[agnostic-apollo]

No hurry since site changes will be done after pre-release.

As for breaking lines, yes, diff can be harder to read, even though there is highlighting, but markdown/html rendering should be left to viewer/browser. When you wrap lines at some x length, then on devices with screen width larger than x (like laptop or large monitors), the text would not consume all the available container div width and will require more scrolling to read text and harder. For devices with screen width lower than x (like mobiles), the text will get wrapped at randomly places and small overflow text will get pushed to a separate line and that too looks bad. Paragraphs should remain continuous text, force wrapping would probably even mess with indented texts/lists. Wrapping makes sense for code files, but not for normal text.

[agnostic-apollo]

Oh I've long since given up on being an AI hater, now I'm just a indigent maintainer dreading having to maintain and support all this AI stuff I have little to no use or interest for.
I'll live, provided I don't end up on GPT-7's hit list.

Sorry, dude, your hate has already been recorded, bu AI overlords won't kill you, they will just punish you by making you moderate their communities, have fun!

[TomJo2000]

Sorry, dude, your hate has already been recorded, bu AI overlords won't kill you, they will just punish you by making you moderate their communities, have fun!

I have no mouth and I must PR.

[Grimler91]

As for breaking lines, yes, diff can be harder to read, even though there is highlighting, but markdown/html rendering should be left to viewer/browser. When you wrap lines at some x length, then on devices with screen width larger than x (like laptop or large monitors), the text would not consume all the available container div width and will require more scrolling to read text and harder.

I agree for html, but think that line-wrapping in markdown is preferred. I thought the generated html would be the same with or without linebreaks, but checked locally with jekyll and that is not the case. So alright, this will not be the hill I die on

[agnostic-apollo]

Content Not Allowed section and mining sub section has been added.

https://github.com/termux/termux-community/blob/site/site/pages/en/rules/index.md#8-content-not-allowed