Reasons for hold

[Peter Blomberg]

Where is the official list of reasons for hold-voting a part?

[Orion Pobursky]

Here's the not all inclusive list, although most of them are now caught automatically by the PT:
https://www.ldraw.org/docs-main/ldraw-or...sages.html

[Peter Blomberg]

Should mirrored studs be elevated to hold?

Can the list be expanded with the following?

Edge overlap in same file - hold
Edge overlap due to different subfiles - hold
Edge overlap due to two copies of mirrored/rotated subfile - warning (current practice)

Duplicated cond line (identical, incl control points) due to subfile - warning (currently accepted)
Duplicated triangle or quad due to subfile - hold

More than 7 decimals used - warning?
More than 10 decimals used - hold?

Move-to file is missing earlier description as comment - warning or hold?

Inefficient use of subfiling - note (opinion)
Inefficient use of primitives - note (opinion)
Inefficient use of quads vs triangles - note (opinion)
Overuse of subfiling - note (opinion)

Move-to matrix is mirroring new part - hold
HELP-line contains code having a mirrored part - hold
Assembly files contain matrix mirroring a part - hold
Rotated stud or stud group - hold

T-junction along "hard" edge line - nothing (current practice)
T-junction at middle of ndis side - warning or note? (currently grudgingly permitted)
T-junction along cond line - warning (current - common error check msg)
T-junction other - warning (current - common error check msg)

Part too high/wide/long - hold
Edge line missing - hold
Cond line missing - hold
Complementary cond line missing - warning (current practice)
BFC error - hold
Stud doesn't fit stud receptacle - hold

Gap due to scaled primitive - what size is allowed?
Gap in freeform tris and quads - what size is allowed?

[Philippe Hurbain]

As a general rule, I'm totally opposed to adding a hold to anything that causes no visual defect.

[Orion Pobursky]

Also, I don't think restating the spec in the form of a hold list is very productive.

[Peter Blomberg]

Also, I don't think restating the spec in the form of a hold list is very productive.

Unfortunately, current practice doesn't always follow the specs. There are unwritten rules and exceptions. The list of things which are permissible, i.e. not causes for a hold, is also not covered by the specs very well. In order for the specs to become more in line with current practices, I do see a need for a discussion where opinions differ.

[Orion Pobursky]

I don't entirely disagree with you.  There some common practices/judgement calls that aren't in the specs and the hold list has it's purpose. What I don't want it to be is a mirror of the specs themselves.

That said, I'm (mostly) with Philo in that for geometry related questions, if there is no visual error it should not trigger a hold. We're starting, in some instances, to cross the line into pedantry in this regard. If you feel you're part has been held inappropriately, appeal to the Admins and we will make a binding decision.

I will depart from Philo in that I think there should be a rigidly defined header and meta data structure.

[Peter Blomberg]

I don't entirely disagree with you.  There some common practices/judgement calls that aren't in the specs and the hold list has it's purpose. What I don't want it to be is a mirror of the specs themselves.

Understood.

As a part-time reviewer, I find it elusive to learn all the exceptions and judgement calls. I make so many mistakes. Sometimes I feel that I just stir up trouble. It would be so much easier if there was something of a reviewer's reference where one could quickly lookup established practices.

As for the quality of geometry implementation, there are no established "good practices". This leaves a lot grey area between 'good quality' and 'violation of the specs'.

[Orion Pobursky]

Sometimes I feel that I just stir up trouble.

Remember: we're all friends and peers here. Any effort made in good faith is welcomed. If you were wrong or overruled take that and learn.

I have committed to fostering an open and friendly community free of toxic gatekeeping and other such nonsense and I intend to keep that commitment. Also keep in mind that for most of us, English is not our primary language and we're conversing in text so misunderstandings in meaning and tone can happen.

As for the quality of geometry implementation, there are no established "good practices". This leaves a lot grey area between 'good quality' and 'violation of the

"Quality" is something that is impossible to quantify and is why we need reviewers. The specs are the hard rules. This leaves the "quality" to be determined and debated by the review process.

[Philippe Hurbain]

I will depart from Philo in that I think there should be a rigidly defined header and meta data structure.

Actually I agree... What I had in mind was just the 3D code 😉