The only problem I see actually is your attitude towards people trying to understand your k3b issue.

For the future:
- Go straight to the point. What developers need is a short explanation about the issue, observed behaviour and expected one (that doesn't necessarily means what you expect shall be the default behaviour, obviously)
- Provide information asked (bug 404313 is currently waiting for information)
- Be respectul. Insulting people will not have the desired effect.

About this bug report, Bugzilla is a community tool.

"Exclusive right of report author over status of their report must be upheld"

That's not the case in any bug report system in the world, commercial or open source.

Despite making a legitimate bug report of an application that fails to comply with established best practices in respect of operations within a foreign system without any prior knowledge of that system or its available resources. 
In which case:
1. am I receiving criticism for being clear in the original bug report? 
2. a written probe into the initial apparent conceptual deficit demonstrated by the code author's initial response resulted in sufficient feedback from the code author to characterise their behaviour as wilful disregard for:
   a) private properties, business schedules and 
   b) equality towards any function other than themself
3. the early intervention by a 3rd party with ambiguous definitions of reference(s) to the chronology of who "was altering the report state inappropriately" did not help a difficult task in dealing with the code author's (code) behaviour or the task of increasing the array of conceptual references to assist 'as would normally be' a temporary array of references, now with the persistent lack of understanding complicated by further interventions by new 3rd parties who have not bothered to follow the Bugzilla template steps to recreate the reported bug beforehand demands persistent references. As for premature enunciations, these are of no consequence, unless they are motivated by such underhand intolerances as misogyny, they are of no consequence.  
4. the off topic responses by the code author and continued unwillingness by them to engage with the terms of the original report it is still unresolved.
5. the purpose of Bugzilla is to encourage the respective author's open discussion, which has not yet occurred.
6. the expected result is an alternative to the naive operation of the buggy code in respect of operating within a private environment, critically not of their own property and without knowledge of the pre-existing machine state while respecting this principle fact by attempting to limit any potential for negative impact by a minimalist self check for a prior instance and validating additional (n+1) instances by asking the system owner to confirm operation (Y/N?).
7. the code author is stating they need proof, demanding further proof beyond, the commitment already, to run their code, to observe their code, to document their code, their code behaviour is immediately at their own command to comply with, as described, a minimalist system check for an instance of the same code identity already in existence on a foreign system, to open a dialogue if and only if code using the same name is already running on that system; in which case the system owner is asked:
 "Please verify you wish to start a fresh instance of K3b (Y/N)?"

Despite being asked to make a video on behalf of the code author I believe it would be far easier for the code author to create a video of the above bugzilla report than for myself since they should already be very familiar with the behaviour of their code. If not, I am forced to ask the question, why not? This is of concern if code is released to the public environment without a full set of use cases and tests beforehand and since the code author has specified a screen recording app. I am given to understand they already have this item?

Given the normal flow of discourse where there is already a problem that impacts a private individual during their work schedule because of a failure to understand best practices. I have performed enough to assist any other users to confirm these findings and for the code author to observe the impact of failing to amend their code appropriately as suggested.

Please read the comments again. Bugzilla is not the right place to discuss these issues.

Christoph, 
1. I accuse you of "Not reading the comments" 
2. I challenge your authority in consequence and the validity of your comments so far for failing to grasp the principle error of the K3b author in failing to respect private property by allowing their code to operate without first validating the system owners consent to run n+1 instances of K3b in an unknown context. The K3b code is an invading object that may otherwise seriously impact the services, resources and business schedule of the system owner!
I demand this matter is referred to a higher committee for Linux Mint to decide on the content of this "Bug Report"
3. I demand that the quality of this BUG is determined by a fresh and non-misogynistic approach by female peers.
Without trying to 2nd guess the intolerance shown towards my attempt to understand the behaviour of yourself, the author and the other 3rd party contributor that appear more concerned with the off topic issues than the actual bug references. 

The continued attack on my attempt to communicate with an unreasonable author (an author without the critical concepts to reason with) has created a hostile "team intolerance" issue that should not exist in an international class code project, referring to the OS upon which the K3b code first exhibited inappropriate naivety towards system resources that were not automatically the property of the K3b author. 

As you have not attended to the principle first you are instead referring to a discussion that results from the apparent inability of the code author to understand the required behaviour of their code in an environment other than their own PC. If you do not perceive this as a bug, then perhaps you have not written code that must observe these rules?

We live in an age of open source, open attitude, but in order to attain these goals we must learn their nature and change with them.

Forced closure before K3b is required to seek consent for subsequent instances of its code (n+1) breaks confidence in validity of Linux Mint to support a truly open source project. Superiority of male dominance over reported content is unacceptable behaviour and should be resisted! This emerging issue is a disgrace!

- K3b is provided with no warranty ("not even the implied warranty of fitness for a particular purpose" such as running on your computer at all). If it doesn't work the way you want, it's not an "invading object" in your computer since you can choose not to use it.

- Linux Mint is not related to, and has no authority over KDE. They are independent projects and communities. This is the KDE bug tracker.

- How can this be about misogyny if your gender is not public information?

Based on your behaviour in both this and the original bug, I am referring this matter to the Community Working Group for further assessment in respect of your compliance with the KDE Community Code of Conduct.

Additionally, please do not utilise the various fields in the bug tracker for purposes outside which they were originally intended.

Created attachment 118197 [details]
attachment-355-0.html

Difficult to comply with something that cannot be seen while under duress
from unreasonable behaviours toward a legitimate bug observation. Again due
to the unreasonable behaviour of the code author towards systems other than
their own and the "team intolerance" demonstrated by the 3rd party
responses toward my attempt to engage the author with those concepts the
author has refused to acknowledge - yet has clearly demonstrated has the
capacity to understand in response to the probe sent to them. All 3rd party
responses have been focussed on "off topic" issues. I have asked this
matter be referred to a higher authority and I have asked for a peer
committee of female members since the pattern of intolerance has been one
of misogyny instead of logic.
Bug reference 404465

On Tue, 19 Feb 2019 at 07:24, Ben Cooksley <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=404465
>
> Ben Cooksley <bcooksley@kde.org> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>       Latest Commit|Request for referral to     |
>                    |higher committee of Linux   |
>                    |Mint                        |
>            Keywords|needs_testcase              |
>                  CC|                            |bcooksley@kde.org
>
> --- Comment #8 from Ben Cooksley <bcooksley@kde.org> ---
> Based on your behaviour in both this and the original bug, I am referring
> this
> matter to the Community Working Group for further assessment in respect of
> your
> compliance with the KDE Community Code of Conduct.
>
> Additionally, please do not utilise the various fields in the bug tracker
> for
> purposes outside which they were originally intended.
>
> --
> You are receiving this mail because:
> You reported the bug.

If your community code refuses to control the behaviour of the code author or to uphold the status of the bug report under control of the report author "until purposeful negotiation in respect of the reported bug has been achieved between the code author and the report author" I challenge your authority to censor the use of fields since otherwise you have allowed this bug to be silenced without resolution! 

This entire episode has been a demonstration of exclusive Hegemony towards a valid and alternate point of view: 

"Authored code must show a minimum standard of code investment viz to demonstrate equality of the contextual systems that are not the property of the code author so to minimize the potential for impact to the otherwise unknown condition, status, business function and acutely the business schedule of the contextual system before a new instance of the authors code is about to run within, i.e. with a dialogue to ask the system owner for consent to run this new instance (Y/N?)" 

Carte blanche operations will no longer suffice in a mature OS environment where negotiation skills must prioritize coherent equality with creative output.

The original bug report author has NOT "intentionally closed" this Bug Report.

This is a test case minus the requested peer group due to the apparent hegemony in preventing field references to broadcast the principle issues.

It is now of interest that this matter is forwarded to Linus for his observation of the attempt to discuss openly the difficulty in discussing meta-programming with an author who remains closed to the idea of a minimal code investment because they are unaware of the impact their code has had and their continued disrespect for the experience this has enforced - yet they are responding with outrage, as too is everybody else! This has confirmed the inequality that has corrupted the discussion of pure logic upon which this report is based to describe the behaviour of the authors code and the author towards their own code as unequal to their regard for the systems within which it is designed to run.

This matter cannot be allowed to continue as it sets a very poor example to the author primarily, to the 3rd party contributors equally for their contributions and the next generation of code authors should this matter occur to them also as an option to their coding as it has occurred to me but has already been well documented by many others and for sound reason. For me to cross the line is exemplary since the code author presented no opportunity to engage equally. I chose to engage the code author directly with a test case to probe the code authors intellectual capacity to understand in case they required a special needs approach to resolve the issue. The response to this probe revealed a mental capacity to respond to impact with emotion equal to that caused by their code behaviour in a foreign system environment with significant impact because consent to run n+1 instances of their code was not sought in principle!

Observers have so far reacted to this event as though I am guilty of bad practice without recognizing either the purpose of the probe or the context of the probe, giving rise to my concern that this culture of coding is indeed hardened to a perspective of meritocracy but to a Newtonian perspective of absolute values. 

Human intellect has already progressed to understand a better framework by observation and evidence of proof. 

That even absolute values are based upon a relativistic framework whereby the context is fundamentally linked to and is equal to the observed object. Such that in order to describe accurately any object, it must be described by its context. 

This framework of obligatory context is called relativity. To drop in a name for future reference, Schrödinger's cat was in an ambiguous state until an inquiry altered its state by nature of the fundamental relationship between object and context.

Normally the principle issue would have remained open to discussion in context to the community of interest. 

However the actions taken to prematurely close and exclude this issue from open discussion is a definitive characteristic of closed thinking which contradicts the historical and core reasoning of the whole of Linux and open source code output. For example the task of merging code streams is dependent upon a relativistic and strategic understanding of the whole perspective of Linux. 

I feel this principle issue deserves recognition by the originating author of Linux because of implicit respect for context in order for this issue to be described in full.

I'm starting to be fed up with your attitude, so read https://bugs.kde.org/show_bug.cgi?id=404465#c8.

A mid-air collision was detected as "testcase" was removed by christophe@krop.fr but without recognition as this context was being written while c@k.fr deleted this field content.

I continue to re-introduce the same field content as the whole commentary/dialogue now stands as a working test case of the principle issue for reference in future. Just as long as my original input is respected for its alternate perspective before a hegemonic disrespect for an individual presentation is allowed to take precedence with a closed mindset. I refer to the evidence of multiple responses to my comments that fail to treat my comments without prejudice. This encourages me to continue to clarify the foundations of my original report and if this is somehow perceived as fundamentally wrong I am at a loss for words to describe the degree of intellectual isolation this indicates. I ask for help since no matter what I say it is being processed with pre-emptive contrariness to the deficit of whatever this community is being categorized with by those who appear not to read the principle issue first?

I cannot write a simple output to screen without a principle library. 
I should not write a single line of code without a principle respect for the owners of the systems my code will run within.

Following discussion with the Community Working Group, it has been decided to indefinitely suspend your Bugzilla account due to your conduct and the manner in which you have behaved towards members of the community.

This will be the final message you receive from Bugzilla.

Created attachment 118205 [details]
attachment-12720-0.html

Because the behaviours demonstrate an irrational defocus from the original
bug observation whilst complaining that I am discussing off topic without
reading the inability of the code author to recognise basic convention of
confirming the system owner's consent to run new instances of their code -
described by myself as a minimalist code investment by my description in
place of a full system audit to reveal likelihood of low probability of
causing system degradation because of critical low resources availability -
to protect the system owner from damage to their immediate business needs
such as work schedule. E.g. system crash destroying current work,
requirement to reboot so disrupting a tight schedule for deadline, etc.

Your statement is contrary to the established principles of open source
cooperation. This observation requires a test case to work through the
principle observation of good practice if not best practice code
submission. How much work would you think you would achieve if code
installed without your consent and consumed all resources in parallel to
your current task and work-flow schedule? If you would choose to ignore
this question to favour your own argument, which I do not and did not
assume any choice by either yourself or the code author, yours, and their
answer would determine the presence of conceptual capacity to engage with
the observation as originally presented in Bug#404313.

The code author in fact chose to ignore the open possibility to engage with
the issue but also demonstrated an emotional response that likewise
demonstrated their capacity to feel outrage over their position being
challenged, i.e. if their work was seriously compromised, they would not
remain unreactive to the fact.

Key to their response to "the probe" is that they cannot understand the
limit of their personal and code boundaries in systems other than their
own. If this principle is likewise not understood by contributors it
amounts to the
 "team intolerance" towards a contributor with an acute sense of
"limitation of boundaries" The acute intolerance towards anything that
crosses "their own boundaries" despite not making these boundaries clear in
anything other than a clan war is transferred as a criticism of the
contributor who is challenging these behaviours! As I have already stated :

"We live in an age of open source, open attitude, but in order to attain
these goals we must learn their nature and change with them."

Since this is not able to be discussed by the current group of contributors
I have asked the whole set of data is transferred to a peer review by
female contributors and preferably by Linux Mint

Alexandra Crawford

On Tue, 19 Feb 2019 at 04:40, Nicolás Alvarez <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=404465
>
> --- Comment #7 from Nicolás Alvarez <nicolas.alvarez@gmail.com> ---
> - K3b is provided with no warranty ("not even the implied warranty of
> fitness
> for a particular purpose" such as running on your computer at all). If it
> doesn't work the way you want, it's not an "invading object" in your
> computer
> since you can choose not to use it.
>
> - Linux Mint is not related to, and has no authority over KDE. They are
> independent projects and communities. This is the KDE bug tracker.
>
> - How can this be about misogyny if your gender is not public information?
>
> --
> You are receiving this mail because:
> You reported the bug.