Since this is happening for both Chris and OpenQA, with a fairly frequent occurrence, I'm definitely
FinalBlocker +1
Currently, I'm not convinced about the BetaBlocker. It is a race condition, it might have a workaround (resize the tiny window, we'll see when Chris replies), and it might be sufficient for Beta (with a CommonBugs entry).

Chris confirmed the window can be enlarged. For me, that seems sufficient for Beta (plus a CommonBugs entry).
BetaBlocker 0

I can also confirm that the window can be resized, it is just a bit tricky to catch the edge of the window correctly, double clicking the upper part works good.
However, I only experienced this in a virtual machine and not on bare metal, therefore I am not sure about how to handle this.

According to the basic criteria the mechanism to create users must be presented clearly and I must admit that a small window can be pretty confusing, which breaks the clearly thing and since it is a basic criterion, it should be a blocker for Beta.

On the other hand, the only thing that is broken is the size of that window, otherwise the functionality is still there, so this could be explained in CommonBugs.

And if it is not a blocker for Beta, it should not be a blocker for Final (otherwise it would have to be a blocker for Beta, too).

For the time's being, I am

BetaBlocker -1

However, I only experienced this in a virtual machine and not on bare metal, therefore I am not sure about how to handle this.

Since it's a race condition, you'd have to perform many more installs to be at least moderately sure that it affects just VMs.

According to the basic criteria the mechanism to create users must be presented clearly and I must admit that a small window can be pretty confusing, which breaks the clearly thing and since it is a basic criterion, it should be a blocker for Beta.

Yes, it's a clear violation of a Basic criterion (there's no weaseling around regarding the window size), but it's conditional (in this case, the condition seems to be "you got unlucky").

And if it is not a blocker for Beta, it should not be a blocker for Final (otherwise it would have to be a blocker for Beta, too).

No, that's not how blocker decision are made. We don't do binary 0/1 decision, if the problem is not binary. We quite regularly postpone the blocker to a later milestone, when the criterion is violated only under certain conditions (certain software configuration, certain hardware, a race condition).

Since it's a race condition, you'd have to perform many more installs to be at least moderately sure that it affects just VMs.

How many? Because I could take my laptop and spend a day with repeating installations of Fedora Workstation on a bare machine and I would be able to do like 16 or 20 installations. Is it enough? If so, I can start right away, but from the statistical point of view, 20 is as little as 2.
And because in the bug, @themurph says he tested on virtual machines, I provided a hypothesis about the bug being VM related. Nothing more.

size), but it's conditional (in this case, the condition seems to be "you got unlucky").

Is this a reason to block? Two years ago, I would say "yes". I am not sure about it today.

No, that's not how blocker decision are made. We don't do binary 0/1 decision, if the problem is not binary. We quite regularly postpone the blocker to a later milestone, when the criterion is violated only under certain conditions (certain software configuration, certain hardware, a race condition).

I know, and I am not happy about this process. Either a criterion is met, or it is not. Anything else is just terminology juggling.

BetaBlocker -1

This happened with me too, since the window can be resized, I am good with it . Additionally, it will be very helpful to have an common bug entry.

How many?

In the bug, Chris says 40% likelihood to hit the bug, Adam says 20-25%. But it's a race, for you it can be 10% or 1%. I'm just saying we can't be "certain" here that it doesn't affect bare metal, and definitely not from 2 attempts. 20 attempts would definitely be more convincing (ideally from more people/different hardware). But I don't think it's really necessary to spend time on this, because it seems frequent enough in VMs, and so if we take it as a FinalBlocker just on that grounds (frequent in VMs, unknown on bare metal), it will get fixed anyway.

I provided a hypothesis about the bug being VM related. Nothing more.

Sorry, I didn't understand that "I am convinced" was a hypothesis ;-)

I know, and I am not happy about this process.

OK, if you know, please don't write the opposite as a fact, that's confusing. You can always suggest a change of approach on test list. The current approach is defined here:
https://fedoraproject.org/wiki/Basic_Release_Criteria#Basic_Release_Requirements (the second paragraph)
https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues.3F
and also in some criteria in their footnotes

Either a criterion is met, or it is not. Anything else is just terminology juggling.

I don't see it as juggling. It's defined and it covers cases where the violation doesn't happen every time. We sometimes do terminology fudging, but this is not it. Either way I'm really happy to discuss proposals for a better approach on the test list.

After a side channel discussion, I and @lruzicka actually agree, just don't use the same terms to express ourselves :-)

To voice my thinking more clearly: I believe this is an obvious violation of the Basic criterion, because it happens in default installations without any tweaking, and quite often (according to presented numbers). So for me, this is definitively a blocker - I wouldn't want to release F33 in this state. Which implies at least the FinalBlocker (therefore my +1). The question is whether we should block sooner (the cited criterion is Basic), i.e. during Beta. My opinion is that since this is a race condition, so far we've demonstrated it just on VMs, and it can be easily worked around (which we'll document), I believe this might be OK for Beta, i.e. we don't need to block on Beta at the moment (which might change as we discover more information). But I don't mind blocking on Beta either, that's why I voted 0.

BetaBlocker -1
BetaFE +1
FinalBlocker +1

Maybe let's agree on BetaFE? It's definitely something that is better fixed than not-fixed :) ...

BetaFE +1

BetaFE +1

BetaBlocker -1
BetaFE +1

Given that it's functional, just annoying, I think it's sufficient for Beta. I'm withholding Final votes in the absence of a better understanding of frequency (and if bare metal is affected).

BetaFE +1

We have BetaBlocker -1 from @adamwill here:
https://bugzilla.redhat.com/show_bug.cgi?id=1875140#c11

I believe that contributes a sufficient number of votes for BetaBlocker and BetaFE:
AGREED RejectedBetaBlocker AcceptedBetaFE

The following votes have been closed:

• Rejected BetaBlocker (+0, 1, -4)
  • 0 by kparal
  • -1 by lruzicka, sumantrom, frantisekz, bcotton
• Accepted BetaFE (+5, 0, -0)
  • +1 by frantisekz, kparal, lruzicka, bcotton, sumantrom

AGREED AcceptedFinalBlocker

Discussed during the 2020-09-08 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criterion:

"A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system".

When the bug happens, g-i-s is not "clearly presented".

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-09-08/f33-blocker-review.2020-09-08-16.00.txt

The following votes have been closed:

• Accepted FinalBlocker (+2, 0, -0)
  • +1 by kparal, frantisekz

Release F33 is no longer tracked by BlockerBugs, closing this ticket.