how many successfully Test are at a Patch (0, 1 or enough)

There should be no difference between 1 or none. And as it goes RTC with 2 tests i think this is clear ;)

is a patch Code-Review or testing

Any patch can be tested using testing. The Problem is that often there are not enough testers. And you can't detect that this is a Code-Review patch using code sometimes the submitter maybe think this is a simple PR but than e.g. the maintainer decide this need more testing ;)

are other testing this patch (like "I check this Patch out to test in next 6 Hours")

hmm we don't have such a feature or i miss something? What is the problem if someone have this on his todo? ?

If he comes back with the results it is not probelm to test a PR that allready had 2 tests.? I don't understand the usecase of that. (Expected if we are in a PBF Event where maybe 10 people test the same patch) But i think this should be handled by the orga of the Event.

using Labels: is a patch i.E. "UX" oder something like "Cody Style"

We have that labels. The Problem is when this is a UX patch? Anything that changes the interface or just?
About CodeStyle you can't automatic detect if the PR are codestyle changes or not (without a human brain ;))

Priority: is a Patch more needed, because it is blocking other Patches, if it is not tested.

There is a priority system. But it did not handle blocking PRs it is more about how much is the impact of the issue. (And Issue is <> PR here)
Maybe there can be something implemented for the release-blocker label so it can be sorted like the RTC tag or marked in the GUI?

@zero-24 Thanks for your Answer. The Points i listed are about Problems i have to use Patchtester smoothly. Maybe others without Knowledge like me can test easier – that the thinking behind my Points.

There should be no difference between 1 or none. And as it goes RTC with 2 tests i think this is clear ;)

Example: A Patch have 2 succesfully Tests, but is not marked as RTC > there is no sign in Patchtester to see this Circumstance.

And you can't detect that this is a Code-Review patch using code sometimes the submitter maybe think this is a simple PR but than e.g. the maintainer decide this need more testing ;)

There are Patches with "Testing by Code-review" > i mean this kind of Patch. Now i have to read the Instructions to see, its about my Possibilities. If theres a Label "Code-Review", i dont have to look at this Patch.

hmm we don't have such a feature or i miss something? What is the problem if someone have this on his todo? ?

It was a Wish to have this kind of feature. Example: It takes Time for me to understand what is to Test, it takes Time to build and Test and retest and after this time i see that three other have test in the meantime. So: this feature can show, that a Patch is going to be tested in an given Time and i can test another, where no one is testing.

We have that labels. The Problem is when this is a UX patch? Anything that changes the interface or just?

i meant to show the Labels they are used now in github. i understand that this is not always clear but if its clear it helps to see "oh, this is something thats my interest and my knowledge".

There is a priority system. But it did not handle blocking PRs it is more about how much is the impact of the issue. (And Issue is <> PR here)

i see today the request for three PR to RTC so they can work on other PRs. So i thought if this make sense its fine for Testers to know about.

At the End: Its more Work for Maintainers to set Labels or code a check-out-function for Patchtester or prioritize Issues. On the other Side this Enhacements (or better one) allows People like me to invest their Time easier.

This isn't possible without writing an API into the issue tracker and rewriting the component to pull data from there. All of the information you want is in the issue tracker, not the GitHub issues. Additionally, no patch should ever be "code review or testing", everything SHOULD require testing. Likewise, no patch is "checked out" for testing, anyone's welcome to test anything at any time.

@mbabker I will try to work with Issue-Tracker. I do there only the "un/succesfully" Mark, all other i was in github.