Guidelines for contributing under CONTRIBUTING.md

[tlaurion]

Any comments welcome! This sets guidelines for contributions to heads and heads-wiki repos.

Thanks for your collaboration into drafting this with me!

[tlaurion]

@SergiiDmytruk: I see you downvoted OP. Comments please?

[SergiiDmytruk]

Codes of conduct suck like any other form of censorship and policing, thus they must not be used unless really necessary. I see no necessity in them (see no argumentation to the contrary in this PR) and avoid projects which use them if I can because if the first thing that is thrown at me is a list of things to discriminate users for, there must be something wrong with the project.

[tlaurion]

@SergiiDmytruk anything against content of contribution.md? I can get rid of code of conduct without any personal issue, all projects I looked around were providing both. Don't see necessity for it, will remove.

[SergiiDmytruk]

anything against content of contribution.md?

No, nothing, I think it can be useful.

[Thrilleratplay]

Codes of conduct suck like any other form of censorship and policing, thus they must not be used unless really necessary. I see no necessity in them (see no argumentation to the contrary in this PR) and avoid projects which use them if I can because if the first thing that is thrown at me is a list of things to discriminate users for, there must be something wrong with the project.

@SergiiDmytruk I think your argument for censorship is misplaced. I see a "code of conduct" a contract for everyone. It protects you from having this or any comment you made being deleted by project maintainers as it states that everything will be reviewed. While the exact manner of arbitration is not stated, the same code of conduct gives you leverage to argue any complaint to the community in different forums (Matrix, Slack, Reddit, etc). The sad reality of the internet is that while it provides unlimited measures of creativity and insight to projects like there, there is still a level of noise that can distract open source maintainers from required tasks. Burn out is a very real issue with open source projects, just search HackerNews. Code of conducts give the maintainers something to point to when they feel like someone is being too abrasive and gives that same user a list of rules to point at when they feel a maintainer does not respect their opinion.

See it more as a Ulysses pact. It is easier to add one now when it is seen as unnecessary then when it tensions are high within a community. It, like everything else in this project, is subject to changes through pull requests. If something is missing or should be redefined, do so by reviewing the document is this PR.

I want to mention that I too an against censorship but the solution to it is not anarchy, it is discourse.

[SergiiDmytruk]

@SergiiDmytruk I think your argument for censorship is misplaced.

Unsurprisingly, I disagree :)

It protects you from having this or any comment you made being deleted by project maintainers as it states that everything will be reviewed.

In practice you'll be banned if some mod wants it.

Burn out is a very real issue with open source projects, just search HackerNews.

I view burn out as orthogonal to code of conduct. People get tired, interests change. If you want to do it, you won't get discouraged easily and if you're not motivated, you'll blame it on rude people or pretty much anything.

See it more as a Ulysses pact.

Self-censorship? This is the same as censorship, because the ultimate goal of censorship is to make people obedient enough so that they censor themselves and think that they do it on their own accord.

It is easier to add one now when it is seen as unnecessary then when it tensions are high within a community.

Sounds a lot like a typical censorship law legislative process:

• Step 1: add the mechanism while downplaying its effects (the scope is tiny, the cause is noble, only "bad people" will be affected)
• Step 2..N: extend the mechanism, grow the scope one thing at a time, censor people who don't like it
• Step N: censor anything you want

I want to mention that I too an against censorship but the solution to it is not anarchy, it is discourse.

Absence of a problem doesn't need a solution. Free and open source software existed for decades without any codes of conducts just fine.

[tlaurion]

Once I unbrick my nv41, I will remove code of conduct for the moment.

Bemol:I think the code of conduct would still be useful to have as a base but basically as of today, it should simply point to the contributing file. As of today, nothing drifted to legitimatize the content of this file, but as @Thrilleratplay pointed out, but in my own words, I saw this as a basic social contract and wasn't shocked by the content that was proposed to put inside of it: so I went forward not thinking there would be adversity.

Anyhow, I would still appreciate a thorough review of CONTRIBUTING.md, and then if nobody strongly disagrees with the code of conduct to be a social contract of contributionnism pointing to the reviewed contributing.md, that's what I would do. Please comment.

And both files expected to imprivd over time, where CI should do linting etc that would not require anything else too complicated and warn users, and myself, of typos and general formatting preferences drifts prior of being merged, responsibilizing contributors.

@SergiiDmytruk im highly motivated in continuing to maintain Heads, but as of today, contribution social contract is missing and sometimes, maintaining Heads and repeating myself all the time is tiring me and making me drift from priorities.

My goal is to make a clear statement that issues and PR are needed, and that documentation improvement is a community effort where code fixes are also welcome. The former not requiring git signature to lower bar of contributions, where the latter is a bit more advanced and require both more technical knowledge of Heads and commit signing. Outside of that, I'm without opinion.

Thoughts @Thrilleratplay @SergiiDmytruk ?

[SergiiDmytruk]

@tlaurion, what you're describing sounds like a process optimization rather than a social contract to me. Documenting things and pointing to them instead of repeating yourself is a good idea. I wouldn't bother complicating the matters by adding a redirection to CONTRIBUTING.md as the name of that file seems clear enough on its own.

On the contents of CONTRIBUTING.md, I think that if you keep it short (current length seems about right) there is a chance that people will actually read it. Couple things I'd consider adding there:

• a recommendation to use spoilers for relatively large logs when the spoilers are available
• preference for GitHub issues over Matrix because I find the former easier to read and manage

In general, I'd avoid demanding too much from contributors because then people might not do anything or might spend a lot of time on something incredibly trivial. For example, as a maintainer it should take much less time for you to find a duplicate than it takes for someone who looks at Heads for the first time because you can just recall it even if the problem was phrased differently. I'd also try to rely more on things like issue/PR templates (as long as they don't ask for a ton of things) and CI checks, this way there is less need to expect people to find information in a file.

[Thrilleratplay]

I still disagree regarding a code of conduct being censorship, it has far less impact than a contributing document.

preference for GitHub issues over Matrix because I find the former easier to read and manage

Given the Matrix channel has been deprecated or the link on the community page is out of date, using Github Discussions will preserve answers and can be searched within the project on Github. This would hopefully cut down on the needing to repeat the same answers, even if it is to link someone to the answer.

[SergiiDmytruk]

Given the Matrix channel has been deprecated or the link on the community page is out of date

I don't think https://matrix.to/#/#OSFW-Heads:matrix.org is deprecated, there are regular messages. I forgot about Discussions which are even enabled here, could be worth mentioning at https://osresearch.net/community/.

I wonder if treating GitHub and Matrix the same in terms of requirements helps or makes things harder. Maybe it makes sense to allow quick free-form questions on Matrix and move to GitHub if subject turns out to be non-trivial. Concentrating on a single place could make maintaining easier and avoid requiring to search in several places (yet to have a good Matrix search experience). People that don't want to register on GitHub could still report things on Matrix by following GitHub instructions as an exception.

[tlaurion]

I still disagree regarding a code of conduct being censorship, it has far less impact than a contributing document.

@Thrilleratplay mind to expose more of your thoughts on that one?

preference for GitHub issues over Matrix because I find the former easier to read and manage

Given the Matrix channel has been deprecated or the link on the community page is out of date, using Github Discussions will preserve answers and can be searched within the project on Github. This would hopefully cut down on the needing to repeat the same answers, even if it is to link someone to the answer.

Matrix channel is pretty alive, and referenced by the community page. The slack bridge is dead. Seems like this one is also unclear....

[Thrilleratplay]

mind to expose more of your thoughts on that one?

@SergiiDmytruk and I do not see eye to eye on what constitutes censorship. I believe heads has thrived due to your diligent efforts @tlaurion and the community is very supportive. All of this has been done without a code of conduct; because of this, adding one is not necessary but I thought it would be a good preventive measure in case any of this changes for the worse. Does that clarify my comment?

Matrix channel is pretty alive

My apologies. I still have "OSFW - Heads" listed in my Element history and confused this with the active Heads channel.

[tlaurion]

mind to expose more of your thoughts on that one?

@SergiiDmytruk and I do not see eye to eye on what constitutes censorship. I believe heads has thrived due to your diligent efforts @tlaurion and the community is very supportive. All of this has been done without a code of conduct; because of this, adding one is not necessary but I thought it would be a good preventive measure in case any of this changes for the worse. Does that clarify my comment?

I think I will remove code of conduct altogether but my question was targeted to the content of CONTRIBUTION.MD @Thrilleratplay :)

Matrix channel is pretty alive

My apologies. I still have "OSFW - Heads" listed in my Element history and confused this with the active Heads channel.

Yeah. Hopefully the bridge will be repaired, but out of my control.

[Thrilleratplay]

@tlaurion Sorry, the content of CONTRIBUTION.MD LGTM.

[fhvyhjriur]

I am also more against this addition. In my experience after few years, i know that it would hold back some small fraction of the good people and wont stop any people that ignores in general everything and just do their thing.
There are big projects that use other git-servers and only copy over to github. Those projects do not use the issue tracker on github and also tell even on the main page that they do not use the issue tracker from github and paste a link to the correct issue tracker. Do you think this stops people who do not care about what is written somewhere from ignoring everything and still use the github issue tracked? No.

At the moment the CONTRIBUTING.md would stop me contributing to heads because of for example this:
Ensure your code adheres to the project's coding standards.

The coding standards include the need of signing a PR to my understanding. But i cant sign when i create a PR with the github website. I described this here: #1728 (comment)
Here a second person who use the github website and also seem to not be able to sign a PR: #1727 (comment)

Summary in short: The try of more regulation is not needed in this project to what i have seen. The project is working great and all people are nice and really productive. More and more bureaucracy is not something good. Lets keep the basic github bureaucracy we all accepted by registering here. It already does forbids some of the parts that you in addition try to also regulate.

[SergiiDmytruk]

But i cant sign when i create a PR with the github website.

The "signing" is just adding Signed-off-by: ... at the bottom of a commit message. If you can specify a commit message (which seems to be the case; I've never edited in the browser), you can sign. Not sure if changing a commit message after creating a PR is possible though.

[tlaurion]

I am also more against this addition. In my experience after few years, i know that it would hold back some small fraction of the good people and wont stop any people that ignores in general everything and just do their thing. There are big projects that use other git-servers and only copy over to github. Those projects do not use the issue tracker on github and also tell even on the main page that they do not use the issue tracker from github and paste a link to the correct issue tracker. Do you think this stops people who do not care about what is written somewhere from ignoring everything and still use the github issue tracked? No.

At the moment the CONTRIBUTING.md would stop me contributing to heads because of for example this: Ensure your code adheres to the project's coding standards.

The coding standards include the need of signing a PR to my understanding. But i cant sign when i create a PR with the github website. I described this here: #1728 (comment) Here a second person who use the github website and also seem to not be able to sign a PR: #1727 (comment)

Summary in short: The try of more regulation is not needed in this project to what i have seen. The project is working great and all people are nice and really productive. More and more bureaucracy is not something good. Lets keep the basic github bureaucracy we all accepted by registering here. It already does forbids some of the parts that you in addition try to also regulate.

@fhvyhjriur if I understand you correctly, your comments are against CODE_OF_CONDUCT.md which was discussed here to be dropped. This is effective as per commit fb4bdc0.

I'm sorry about this security project requiring signing, but once again this is politics and also a somewhat good practice in distrusting infrastructure.

@SergiiDmytruk github commit signoff is a little bit more than just adding a text signature. On github fronted, this could be somehow bypassed by adding Signed-off-by: ..., since github frontend does some voodoo linking authenticated users from web frontend and their interactions there, but from the code base perspective, its about having code digitally signed with PGP to attest of who really contributed code (I don't mind bypassing policy for Docs, but again policy enforced by linuxboot organization here, with their global github action DCO) which I agree with for commits signature. Github then checks provided public key by end users into Github on its web frontend to validate that commits are actually signed with user's key which local git checkout can help spot unsigned contributions; TLDR this is for accountability reasons and repo proper history validation; making sure code contributions were really contributed by actual contributors not someone impersonating them easily. To be honest, I want my commits to be signed with my key and github verifying agaisnt my public key dropped on its servers to provide this accountability and attest that i'm actually the one having signed all those commits. And by extension, for code, I will veto here that for a security project, this should be required and won't budge here @fhvyhjriur. That doesn't mean contributions are blocked; it means that people wanting to contribute code should have a USB Security Dongle to sign their contributions, and if that might seem something that might reduce contributions, its actually not the case since most developers will also do that on their daily developer's life. It might be a gate to entry for small contributions but from my experience, #1728 (comment) and #1727 (comment) are not really good examples of all previous contributions.

Note that Heads is becoming more widespread and needs to adapt, true. But I will remind that I have no problem picking commits, inspecting them and create superseding pull requests of prior unsigned ones for meaningful contributions from testers, for example. But this CONTRIBUTION.md guidelines is for people wanting to contribute in code and docs, and clarify somehow what to do in the goal of easing my maintainership burden so I can continue to do what should matter to most instead of wasting my time repeating myself like I currently do to all those newcomers to the project. We like newcomers, but we need to point them to what is expected of them.

TLDR:
@fhvyhjriur #1727 (comment) is actually a good example for enticing contributions. KGPE_d16 platform is currently unmaintained (I won't go in details why here), but those contributions are meaningful and my time will be invested into showing how those contributions can be bettered. I won;t make signing those commits a requirement per se, but I can bet that Heads users wants commits to be signed from contributors. So I will cherry-pick, sign, and then correct what is missing/not needed there and make a superseding PR. *But Ideally, contributors learn and don't depend on me doing that for all contributions. Testing is one thing, improving docs is another, provinging code changes is a completely different thing while providing kernel config changes for a tested board is also a seperate thing. Managing a project like Heads is complicated. I would appreciate if the feedback I'm receiving trying to improve workflow and contributionism on whole ecosystem (qubes, linux, xen, kexec, gpg, and all other things Heeads depend on) was not as I read it here: "let's keep the status quo" which actually means more work on my side and less on everybody else. I appreciate and desire more contributions, but not from me having less time managing my priorities because users have others. Contributions is exactly the opposite: sharing what worked for others, without the burden of creating such changes being in my hands, while signing commits permit me to inspect, test and merge. Not having to also create superseding PR, which I do not what to do for docs. Here again @fhvyhjriur : yoru change on doc happened in heads repo here; this is why it required signing. Heads-wiki per CONTRIBUTING.md emphased a little more on not requiring heads-wiki to be signed commits, where DCO github action applies globally and on which I have no direct control. I hope this comment makes things a little clearer.

[tlaurion]

@SergiiDmytruk @Thrilleratplay @fhvyhjriur : I would appreciate another small round of review of current PR content and challenges on improving things for all (including myself) without promoting status quo (let's keep things as they are today).

I understand that maintainership burden might not show everyday, and should not show on a daily basis, but this is not my reality. I try to improve things so that I can optimize my time on Matrix, priority support channels from partners, provide great PR reviews, testing, coaching ofr contributions, help improve forks, create vulnerability reports for the ecosystem etc, but time is a limited resource. This is my attempt to have something to point to to newcomers and economize time to do what should be considered important by all Heads users, with users considering my time precious just like I consider their time and contributions precious, with a tradeoff. I might not consider all contributions equally important. And I do not intend to pass more time on contributions I do not consider important more than what I consider my time worth contribution and resolving more pressuring issues with everyone thinking I should do X instead of Y, nor should I have to justify things I have to do in a day that all consume time, without showing neither on gihub or Heads comminity channels.

TLDR: this is an attempt to promote desired contribunionnism for this project, and I would appreciate feddback to improve the content of what is in this PR and best practices guidance into doing so, not promoting status quo. If I decided to go this way, its because this is taking way too much of my time which I try to optimize. Thanks for your conisderation and thorough reviews.

[tlaurion]

Given the Matrix channel has been deprecated or the link on the community page is out of date

I don't think https://matrix.to/#/#OSFW-Heads:matrix.org is deprecated, there are regular messages. I forgot about Discussions which are even enabled here, could be worth mentioning at https://osresearch.net/community/.

I wonder if treating GitHub and Matrix the same in terms of requirements helps or makes things harder. Maybe it makes sense to allow quick free-form questions on Matrix and move to GitHub if subject turns out to be non-trivial. Concentrating on a single place could make maintaining easier and avoid requiring to search in several places (yet to have a good Matrix search experience). People that don't want to register on GitHub could still report things on Matrix by following GitHub instructions as an exception.

@SergiiDmytruk How would you word this out?

[tlaurion]

@SergiiDmytruk @Thrilleratplay @fhvyhjriur Please review current 9ac4e4b's files changes at https://github.com/linuxboot/heads/pull/1719/files and feel free to add comments. suggestions there.

[tlaurion]

@SergiiDmytruk @fhvyhjriur please also change your downvotes if you feel current state of PR makes you change your mind on the proposed changes.

[SergiiDmytruk]

I don't think DCO and commits signatures are integrated in any way (I might be wrong) and thought it's DCO which is an issue here. Commit signing in WebUI might not be in fact available.

That doesn't mean contributions are blocked; it means that people wanting to contribute code should have a USB Security Dongle to sign their contributions, and if that might seem something that might reduce contributions, its actually not the case since most developers will also do that on their daily developer's life.

No security dongle is needed, just GPG key. I think it's an overstatement that signing commits is all that widespread. In coreboot, for example, I don't see GPG-signatures (although Gerrit might be affecting it).

make a superseding PR

As a maintainer, you can typically just push to PR's branch directly after rebasing commits.

I wonder if treating GitHub and Matrix the same in terms of requirements helps or makes things harder. Maybe it makes sense to allow quick free-form questions on Matrix and move to GitHub if subject turns out to be non-trivial. Concentrating on a single place could make maintaining easier and avoid requiring to search in several places (yet to have a good Matrix search experience). People that don't want to register on GitHub could still report things on Matrix by following GitHub instructions as an exception.

@SergiiDmytruk How you you word this out?

Something like the following:

If you're unsure about what kind of issue you're looking at or whether it's an actual issue with the project rather than your usage mistake, feel free to post a quick question briefly (actual amount of details depends on the situation) describing the situation and expect to either get a suitable answer or a request to provide a detailed problem report on GitHub which will be treated with more attention. In case of an absence of a GitHub account and unwillingness to create one, detailed report can also be submitted via Matrix and an issue will be opened on GitHub by a maintainer.

[fhvyhjriur]

By removing this line "By participating in this project, you agree to abide by our Code of Conduct." and replacing it with a line with completely different meaning, you changed my mind from
"i am completely against the whole PR"
to
"Yes, that is fine. When someone read this text, the PR/code output of the person could look better then before reading it and when the whole writing is ignored, then the situation is just unchanged from how it was before the existence of this text."
@SergiiDmytruk thanks for keeping an eye on PR-changes and getting into changing those before they get merged.

And because now the reason is known:

in the goal of easing my maintainership burden so I can continue to do what should matter to most instead of wasting my time repeating myself like I currently do to all those newcomers to the project.

Lets follow this goal. I would for example add that there is no signing needed for changing .md files in this project. This would remove the need of wasting your time in maintainership there.
Also you told that you plan to merge the heads-wiki into this repository. Adding this exception for .md files would help to organize everything so that the freedom in changing the future wiki files is not affected by this upcoming code movement.

That doesn't mean contributions are blocked; it means that people wanting to contribute code should have a USB Security Dongle to sign their contributions, and if that might seem something that might reduce contributions, its actually not the case since most developers will also do that on their daily developer's life.

Lets take the view from of a whistle blowing person that left behind everything in life and could get to a different country and inside a public library. There is a computer free to use when you move the mouse and you can type on the keyboard. You are blocked in using anything else then a web-browser.
The person is advanced IT-person and understand heads, qubes and so on but need a PR merged to get a computer running because its also not possible to compile code for some reasons.
There is no USB Security Dongle, there is nothing the person have. By changing "By participating in this project, you agree to abide by our Code of Conduct." to something that is now optional, this person now can still create a PR and hope the best that this PR get merged.
Do not forget, that its often already a burden to somehow create a private github account to create some PR.

Do never block people on their abilities of not having/owning something.

Because this PR is some exception of the other PR and more political then technical, i would like to point a different and more wide view on the world to make important project affecting decisions more clear.
Example 1: On Wikipedia people can edit without account. Some of the Wikimedia administrators hate this and would like to disable it. At the morning of a day, many children find it funny to edit some Wikipedia page and write down stupid things like "Thomas is eating poo". Then they send the Wikipedia link to others in the class and find it funny to have create a proof that Thomas is eating poo.
Example 2: A teacher in a school is a known Wikipedia editor for years. This teacher changed in Wikipedia a article about a topic to something wrong. Then at the next day the teacher gave the children in the class homework about this topic. All children had wrong homework because they all believed in Wikipedia. The teacher's edit circumvented all security checks Wikipedia had because the teacher was known good editor for years.
Example 3: A woman from China that had lack of social contacts was bored and created an own world about a topic in Wikipedia. She used all the things she created over many years as own source of proof for the different things in the topic. It took many years to find out that all of that what she wrote was just her own fantasy.
Example 4: https://en.wikipedia.org/wiki/XZ_Utils#Backdoor_incident
Example 5: Using cash in paper format to pay other people to corrupt them

Example 1 - should we remove the ability to just press a button without any account (or to keep the topic without any GPG-signature/USB-Key) and change something? No. Because Example 2 and 3 show that its then just more complex to do wrong things. And Example 2 - is this something really bad? Or is writing/doing something wrong to make people more questioning everything a good thing?
Example 4 - using some signature things or any other barriers wont have changed anything there.
Example 5 - should we remove a simple to use private payment in the whole world and track every single money movement? Everyone should have to sign with a digital ID-card(GPG/usb-key) every transfer? No!

Now more into software development: What is the only thing that helps not getting into situations like https://en.wikipedia.org/wiki/Heartbleed ?

1. Free and Open source software
2. As many People as possible who read, understand and edit the code and when something is wrong blow the whistle
3. https://en.wikipedia.org/wiki/Reproducible_builds

Thats all. Every other try to do something else does not work. The text "By participating in this project, you agree to abide by our Code of Conduct." did nothing from the 3 points but blocked the access to the project. Now its gone and all is optional and the goal of the text is to reduce work and that is fine.

Humans should live the "question everything" philosophy and keep the entry point as low as possible (at best no account required, just pressing a edit button and contributing). Then most people could join and the 3 points could be fulfilled at best.
Perfect situation: when all commits to this project from @tlaurion are without any name/account and no one would know what is written from who.
@tlaurion told so often he would like to not have such a central point in the project and more people should join. I understand that point and its a important point. Having the lowest entry point and keeping the lowest possible entry point is important to get to this goal.

I hope this text helped somehow to make it more clear that signing code does not help anyhow because the thrust in the code should come from many people reading it and a public build service combined with reproducible builds. In a perfect world it should not matter if something is signed or not or who have written it. Lets try to live this perfect world in the way of "fake it till you make it".

[tlaurion]

Thanks @SergiiDmytruk for your time reviewing this.

I don't think DCO and commits signatures are integrated in any way (I might be wrong) and thought it's DCO which is an issue here. Commit signing in WebUI might not be in fact available.

Not available, some black magic involved through GitHub user auth and commits considered singed where DCO is verifying is signed off with basic signature without counterfeiting validation whatsoever (not gpg signed)

That doesn't mean contributions are blocked; it means that people wanting to contribute code should have a USB Security Dongle to sign their contributions, and if that might seem something that might reduce contributions, its actually not the case since most developers will also do that on their daily developer's life.

No security dongle is needed, just GPG key. I think it's an overstatement that signing commits is all that widespread. In coreboot, for example, I don't see GPG-signatures (although Gerrit might be affecting it).

Right.
But see https://github.com/coreboot/coreboot/commits/main/ where only unsigned some rare commits are "Unverified".
(weirdly @miczyg1 commits at first glance: why?)

make a superseding PR

As a maintainer, you can typically just push to PR's branch directly after rebasing commits.

Then something is wrong in docs, since we try to entice users into creating forks, do commits there (webUI way) and create PR upstream (also webUI suggested path). Therefore I cannot edit user forks, can only clone user branch, create/modify (co-sign commits) and then create superseding PR, unless I miss something. Any workflow improvements welcome here to streamline processes for community base contribution on forked contributions.

I wonder if treating GitHub and Matrix the same in terms of requirements helps or makes things harder. Maybe it makes sense to allow quick free-form questions on Matrix and move to GitHub if subject turns out to be non-trivial. Concentrating on a single place could make maintaining easier and avoid requiring to search in several places (yet to have a good Matrix search experience). People that don't want to register on GitHub could still report things on Matrix by following GitHub instructions as an exception.

@SergiiDmytruk How you you word this out?

Something like the following:

If you're unsure about what kind of issue you're looking at or whether it's an actual issue with the project rather than your usage mistake, feel free to post a quick question briefly (actual amount of details depends on the situation) describing the situation and expect to either get a suitable answer or a request to provide a detailed problem report on GitHub which will be treated with more attention. In case of an absence of a GitHub account and unwillingness to create one, detailed report can also be submitted via Matrix and an issue will be opened on GitHub by a maintainer.

Will consider all your comments in next edit rounds, thanks again @SergiiDmytruk . Really valuable contribution to my needs and eyes.

[SergiiDmytruk]

Then something is wrong in docs, since we try to entice users into creating forks, do commits there (webUI way) and create PR upstream (also webUI suggested path). Therefore I cannot edit user forks, can only clone user branch, create/modify (co-sign commits) and then create superseding PR, unless I miss something.

You're missing "allow edits by maintainers" checkbox. Typically PR authors allow such edits and you can just git push <fork-url> <branch-there> and then merge in UI or locally.

[tlaurion]

@SergiiDmytruk @Thrilleratplay @fhvyhjriur : quick review/approval please?

[SergiiDmytruk]

LGTM, but there is a formatting nit that could be addressed to make it look less confusing.

[tlaurion]

@SergiiDmytruk thanks for approving this PR and drafting it with me.

@Thrilleratplay @fhvyhjriur feel free to propose further changes... following the now merged contribution guidelines :)