What requires a HOLD vote on the Parts Tracker

[Orion Pobursky]

We've created this new forum that is only viewable by PT Authors and Reviewers to allow candid discussions regarding Parts Tracker issues. To kick things off, there has been some internal discussion about what, exactly should require a HOLD vote for a part.

Since I'm the one posting this, I'll start with my suggestions:

Things the should require a HOLD:
- Wrong part number
- Wrong or questionable origin
- Invalid syntax
- Blatantly wrong geometry

Things that should generate a warning but not a HOLD:
- Small gaps
- Wrong KEYWORDS or CATEGORY
- Semantics issues like, this should be a subpart
- Anything that the PT Admin can fix (e.g. Header issues)
- Minor color problems
- Basically anything that can be fixed after initial release without breaking models that use the part.

PT Admin shall have the final say on all Parts issues.

[Willy Tschager]

Officially we have only the outdated L3P error list:

http://www.ldraw.org/library/tracker/ref/l3pmsg/

while most of us use the output of Datheader (the following list was kindly provided by Mike Heidemann, author of the prog):


1    ERROR    Embedded POV Code found.    HOLD
2    ERROR    '0 WRITE' found. - HOLD
3    ERROR    '0 BFC CERTIFY INVERTNEXT' found.    HOLD
4    ERROR    '0 ROTATION' found.    HOLD
5    ERROR    '0 COLOR' found.    HOLD
6    ERROR    Incorrect use of only '0' for comments. Should be '0 //' instead.
7    ERROR    Not all used colors in LDConfig.ldr.    HOLD
8    ERROR    Matrix all zero found.    HOLD
9    ERROR    Identical vertices found.    HOLD
10    ERROR    Colinear vertices found.    HOLD
11    ERROR    Bad Vertex Sequence found.    HOLD
12    ERROR    Concave quads found.    HOLD
13    ERROR    Coplanarity.    HOLD
14    ERROR    Incorrect color for linetype.    HOLD
15    ERROR    Loop in reference found.    HOLD
16    ERROR    Double lines found.    HOLD
17    WARNING    Maybe wrong color for sticker used.
18    ERROR    Length of part description.    HOLD
19    WARNING    Maybe leading spaces in part description.
20    ERROR    Keywords entry length.
21    ERROR    Some keywords are also in part description.    HOLD
22    ERROR    Filename does not matches filetitle.    HOLD
23    ERROR    Author real name is not set.
24    ERROR    Author user name is not set.
25    ERROR    BFC is not set.    HOLD
26    ERROR    License is not set.    HOLD
27    ERROR    Part type is not set.    HOLD
28    ERROR    Primitives needs to have CCW winding.    HOLD
29    ERROR    Use of !KEYWORDS is not allowed for this part type.    HOLD
30    ERROR    Part description contains Tab character.    HOLD
31    ERROR    HELP entry length.
32    ERROR    Word 'new' or 'old' is used in part description.
33    ERROR    Use of (Needs work).    HOLD
34    ERROR    Entry for !CATEGORY.
35    ERROR    Use of !CATEGORY is not allowed at for this part type.
36    ERROR    High-res primitive has to start with '48\'.    HOLD
37    ERROR    Description for primitives should not start with '_' or '~'.    HOLD
38    ERROR    Filename for parts, shortcuts and primitives should not start with '48\' or 's\'.    HOLD
39    ERROR    Filename for subparts has to start with 's\'.    HOLD
40    ERROR    Description for subparts has to start with '~'.    HOLD
41    ERROR    Description for subparts should not start with '_' or '='.
42    ERROR    Description for parts should not start with '_' or '='.
43    ERROR    Description for shortcuts and/or physical_colour parts has to start with '_'.    HOLD
44    ERROR    Filename for shortcuts contains usually a 'c' or 'd'.
45    ERROR    Extension has to be .dat    HOLD
46    ERROR    Special characters in description not allowed.    HOLD
47    ERROR    Lines do not end with <CR><LF>.
48    ERROR    Author !HISTORY entry has no brackets.
49    ERROR    Not scalable primitive is scaled.
50    ERROR    primitive is scaled not only in Y direction.
51    ERROR    First line after BFC INVERTNEXT isn't linetype 1.
52    ERROR    Problem with the RGB value.
53    ERROR    '~Moved to' file used.
54    ERROR    Wrong BFC command found.
55    ERROR    Some keywords are used twice in KEYWORDS section.    HOLD
56    ERROR    'Minifig Accessory' found in part description.
57    ERROR    'Figure Accessory' found in part description.
58    WARNING    'INVERTNEXT' used although not necessary.
59    WARNING    TJunktion detected.
60    ERROR    Wrong brackets around username used. Only [] is allowed
61    ERROR    Description for alias parts should start with '='
62    ERROR    Description for Physical_Colour parts should mention the used colors
63    ERROR    Only linetype 0 and 1 are allowed in Physical_Colour parts.
64    ERROR    Wrong color (16 or/and 24) used for Physical_Colour part
65    ERROR    Only linetype 0 and 1 are allowed in Alias parts.
66    ERROR    Only one (1) linetype 1 is allowed in Alias parts.
67    ERROR    Only color 16 is allowed in Alias parts.
68    ERROR    Alias needs to be mentioned in the comments in the form 'Alias of partnumber'.
69    ERROR    Mentioned part number in the alias comment is wrong.
70    WARNING    Origin is outside the Boundingbox.
71    ERROR    American English words used in part description.
72    WARNING    Too much empty lines at the end of the file.
73    WARNING    Mirrored studs detected.
74    WARNING    Flat subfile scaled in flat direction
75    ERROR    Optional line with same vertices than line found.
76    ERROR    Leading or trailing zeros found.
77    ERROR    Overlapping triangle found.
78    ERROR    Lines with wrong number of arguments found.
79    WARNING    Filename ending does not match declared LDRAW_ORG file type.
80    ERROR    Moved To setnumber with Extension    HOLD
81    WARNING    Filename ending does not match declared LDRAW_ORG part type qualifier.


w.

[Orion Pobursky]

while most of us use the output of Datheader (the following list was kindly provided by Mike Heidemann, author of the prog):

While I like DATHeader, it's Windows only. I'd like to see a browser based solution. Ultimately, I'd like the PT to check this errors automatically. Both of these solutions are a long way off unless we get a volunteer coder to help us out.

[Philippe Hurbain]

I mostly agree that we are too strict overall... But another thing to factor in is the scarcity of reviewers. If I don't like something in a part I put a novote with comments, but there are so few reviewers, who could overwhelm my opinion, that a hold -  somehow forcing the author to react - would perhaps be better...

[Santeri Piippo]

while most of us use the output of Datheader (the following list was kindly provided by Mike Heidemann, author of the prog):

While I like DATHeader, it's Windows only. I'd like to see a browser based solution. Ultimately, I'd like the PT to check this errors automatically. Both of these solutions are a long way off unless we get a volunteer coder to help us out.

I could possibly help with this.

[Santeri Piippo]

I generally ask myself: is it necessary to fix the problem to release the part? If a wrong color is used, it will affect the end user a lot more than a missing contour. Concave quadrilaterals can cause misinterpretations by software so those, of course, must be fixed. A BFC error can cause potentially major rendering issues so those should always net a hold vote. A t-junction, that might cause some minor rendering artifacts and I try to avoid them in my work but I don't see why it should necessitate a hold vote. Or minor gaps or bleed-ins that generally are not visible unless you take a very close look at it.

I think that we often find problems (such as t-junctions) that would be nice to fix but shouldn't cause problems in by far most use cases. Currently these get a hold vote or, like Philo said, we keep back our certify votes for. The only current alternative is, right now, to put a "(Needs work)" qualifier which to me carries the connotation that the part requires major rework and we generally don't use it for simple problems.

We should keep in mind that generally people want these parts to build models with, and models have a scale much larger than what we as parts authors deal with. Our scale is 0.1 - 100 LDU or so in most cases; for models, 100 LDU is just the length of a 5 stud brick!

So perhaps we need better a platform for that? Maybe a list of issues (like a bug tracker of sorts) somewhere on the PT which would list parts that are released with issues, minor or major. Major issues are those that we currently apply the "(Needs work)" treatment to. Minor issues would then be ones that we can fix in a future update. Then we would have less issues to raise a hold vote for, or to keep back a certify for. Instead, release and put a note down that we should fix this later. This will probably create a backlog of things to deal with but that would still be better than a hundred parts held back for minor issues that aren't getting updates for years to come. Prioritize.

Perhaps there could also a third category for things that would be nice but what aren't realistic to deal with right away?

(nth) Edit: I also thought that a major part of the problem seems to be that when the part is released, it disappears from the parts tracker and needs to be re-submitted to it to be edited again, losing comment history in the process. So our only options are to release or keep it on the PT. I think that these shouldn't be mutually exclusive. A part with non-showstopper issues could be both released and kept on the PT for rework. A part with major issues can be released with a Needs Work modifier. Why does releasing a part remove it from the PT entirely anyway instead of just archiving it?

[Magnus Forsberg]

I don't think we should lower our standards only to get more parts released.
Making a list of parts with known issues is just a waste of time and effort. No one will ever rework that list of parts. Look at the list of parts with known BFC errors on the PT. No one was working it, untill I decided to do that.

What we need are more active rewiers and more responsive part authors. Uploading a part and not responding on a review is a waste of the reviewers time and effort. 
If I give a review in a Novote and the author ignores my opinion, I'm not likely going to review his next part. A second reviewer will ignore the file. Someone else has already revied it, and found some errors in it. Giving a Hold-vote is the only way to move things forward. I'm only allowed to change a bad file that have a Hold vote.

I also don't like the trend we are currently seeing. A sprint of hasty reviews only to get parts into the next release. Making parts take time, and reviewing them also takes time, and isn't something that should be done in the last minute. I prefer a more constant stream of releases, giving us a chance to quickly correct any faulty parts that needs recycling.

[Willy Tschager]

While I like DATHeader, it's Windows only. I'd like to see a browser based solution. Ultimately, I'd like the PT to check this errors automatically. Both of these solutions are a long way off unless we get a volunteer coder to help us out.

I could possibly help with this.

For sure? I'd welcome this.

w.

[Willy Tschager]

I'm not concerned about the errors that can be fixed with a set of rules but when HOLDs are given based on "believe":

* I believe .... this is a subpart, part, shortcut, color xxx, ...

I think the final decision on part numbering, description and file type should be entirely up to the PT admin. Part authors might give suggestions but not HOLD them - 'cos with the system in place a HOLD cannot be overruled, not even with 10 CERTIFIED and an admin CERTIFIED. A HOLD has all the power a CERTIFIED has none.

w.

[Willy Tschager]

To proceed I suggest a hand down approach with revising Mike Heide's list as a starting point for Santeri Piippo if he is willing to code this up.

w.

[Santeri Piippo]

To proceed I suggest a hand down approach with revising Mike Heide's list as a starting point for Santeri Piippo if he is willing to code this up.

w.

A web based part checker? Sure, I could use such a thing too since I also use Linux.

I'll get started on the groundwork.

[Willy Tschager]

Since there a almost 80 position I suggest to work on them in a block of five. So the question is should these trigger a HOLD vote or just a WARNING (comment)?

1    ERROR    Embedded POV Code found.    HOLD 
2    ERROR    '0 WRITE' found. - HOLD 
3    ERROR    '0 BFC CERTIFY INVERTNEXT' found.    HOLD 
4    ERROR    '0 ROTATION' found.    HOLD 
5    ERROR    '0 COLOR' found.    HOLD

I further suggest that if a part gets certified with non resolved warnings those should be documented by a simple comment in the part itself.

w.

[Philippe Hurbain]

Since there a almost 80 position I suggest to work on them in a block of five. So the question is should these trigger a HOLD vote or just a WARNING (comment)?

1    ERROR    Embedded POV Code found.    HOLD 
2    ERROR    '0 WRITE' found. - HOLD 
3    ERROR    '0 BFC CERTIFY INVERTNEXT' found.    HOLD 
4    ERROR    '0 ROTATION' found.    HOLD 
5    ERROR    '0 COLOR' found.    HOLD

I further suggest that if a part gets certified with non resolved warnings those should be documented by a simple comment in the part itself.

w.

For sure 2, 3 and 4 (and actually I think all 5) could and should be autocorrected by the validator. Actually that's what DH does...

[Max Martin Richter]

Since there a almost 80 position I suggest to work on them in a block of five. So the question is should these trigger a HOLD vote or just a WARNING (comment)?

1    ERROR    Embedded POV Code found.    HOLD 
2    ERROR    '0 WRITE' found. - HOLD 
3    ERROR    '0 BFC CERTIFY INVERTNEXT' found.    HOLD 
4    ERROR    '0 ROTATION' found.    HOLD 
5    ERROR    '0 COLOR' found.    HOLD

I further suggest that if a part gets certified with non resolved warnings those should be documented by a simple comment in the part itself.

w.

All five should result in a hold vote. They can be fixed by the validator but there is the need of a visual check of the part and code by the parts author.

[Gerald Lasser]

Since there a almost 80 position I suggest to work on them in a block of five. So the question is should these trigger a HOLD vote or just a WARNING (comment)?

1    ERROR    Embedded POV Code found.    HOLD 
2    ERROR    '0 WRITE' found. - HOLD 
3    ERROR    '0 BFC CERTIFY INVERTNEXT' found.    HOLD 
4    ERROR    '0 ROTATION' found.    HOLD 
5    ERROR    '0 COLOR' found.    HOLD

I further suggest that if a part gets certified with non resolved warnings those should be documented by a simple comment in the part itself.

w.

1, 2 and 4 : Autocorrect, delete the code, it is not requird in a part. WRITE may contain a comment, so maybe remove WRITE and reformat to a proper comment

3: Autocorrect, change to the proper command

5: Not sure, may be used in prints or stickers?

Edit: May be we shall use a Google doc sheet or something everybody can edit in the browser to collect the views.

[Santeri Piippo]

Edit: May be we shall use a Google doc sheet or something everybody can edit in the browser to collect the views.

Agreed. This is going to get real confusing if we do this in a forum thread.

[Johann Eisner]

Hello and good evening

I read this topic with great enthusiasm, and would like to comment on it.
Although I am still a young partauthor, but I also think that quality should be more important than quantity.
Although I was annoyed at the beginning, when I received the first "HOLD" for a simple sticker.
In retrospect, I was able to understand the holds very well. It was only minor things, but it was just mistakes.
I just think it's a pity people do not fix the mistakes when they get a hold.
Certainly, a lot of work and time is required to check the parts very carefully, but at the end of the day it's just 99.99% perfect parts.
If there is a routine for checking the parts in the PT, this is also beneficial to the parts author. Thus, he immediately sees the big mistakes and can repair them even before the first upload.
Has the advantage that less defective parts are uploaded to the PT and parts do not have to be checked by the reviewers as often.
Saves resources and thus raises the quality and quantity.

Regards Johann

[Gerald Lasser]

Edit: May be we shall use a Google doc sheet or something everybody can edit in the browser to collect the views.

Agreed. This is going to get real confusing if we do this in a forum thread.

I did the frame work for it, let me know if you can access & edit
https://docs.google.com/spreadsheets/d/1...sp=sharing

[Damien Roux]

Just to give my point of view: as long as the reviewer and the author can discussed about a controvertial « hold » vote, I see no reason not to be strict.

As for me, anything related to part structure, anthoring rules or anything clearly defined in the standards should be holded, and the author must correct it.
Then, when it comes to pattern, complex surfaces geometry or anything that can get different interpretation, a hold vote should be clearly justified and the reviewer should be openned to discussed it, taking into account the author’s aguments. As for me, the tracker is already working that way.



Talking about my part’s reviews: I can’t complain because I try to correct holded parts asap and I never felt « hold abuse » from the reviewers (who I thank a lot btw).

Less « hold » is not what we need to get certified parts faster. What we need is an army of reviewer/authors to get the tracker to zero pending parts. If I would be an active reviewer, I would be kinda feared of this huge amount of parts waiting to be certified, and I wouldn’t know where to start. Cleaning the tracker would be a good start I guess, but that’s not an easy job.

[Chris Dee]

To proceed I suggest a hand down approach with revising Mike Heide's list as a starting point for Santeri Piippo if he is willing to code this up.

w.

A web based part checker? Sure, I could use such a thing too since I also use Linux.

I'll get started on the groundwork.

Please don't start something independent. The best way to do this is to integrate it into the Parts Tracker. Please PM me and we can discuss.

[Chris Dee]

I also don't like the trend we are currently seeing. A sprint of hasty reviews only to get parts into the next release. Making parts take time, and reviewing them also takes time, and isn't something that should be done in the last minute. I prefer a more constant stream of releases, giving us a chance to quickly correct any faulty parts that needs recycling.

More frequent releases is definitiely the way forward. I'd like to move to at least a three-monthly schedule, as I should have more time next year (and I'm working hard to get an update out before the end of 2017).

[Chris Dee]

I also thought that a major part of the problem seems to be that when the part is released, it disappears from the parts tracker and needs to be re-submitted to it to be edited again, losing comment history in the process. So our only options are to release or keep it on the PT. I think that these shouldn't be mutually exclusive. A part with non-showstopper issues could be both released and kept on the PT for rework. A part with major issues can be released with a Needs Work modifier. Why does releasing a part remove it from the PT entirely anyway instead of just archiving it?

This would be a substantial change to the (already complex) way the update build process works, but that is not to say it is impossible. The review history is archived - there just isn't a web interface to display it.

[Willy Tschager]

Agreed. This is going to get real confusing if we do this in a forum thread.

I did the frame work for it, let me know if you can access & edit
https://docs.google.com/spreadsheets/d/1...sp=sharing

Gerald, so you're going to do all the paperwork :-) Fine with it.

w.

[Willy Tschager]

Since there a almost 80 position I suggest to work on them in a block of five. So the question is should these trigger a HOLD vote or just a WARNING (comment)?

1    ERROR    Embedded POV Code found.    HOLD 
2    ERROR    '0 WRITE' found. - HOLD 
3    ERROR    '0 BFC CERTIFY INVERTNEXT' found.    HOLD 
4    ERROR    '0 ROTATION' found.    HOLD 
5    ERROR    '0 COLOR' found.    HOLD

I further suggest that if a part gets certified with non resolved warnings those should be documented by a simple comment in the part itself.

w.

1 Remove
2 Convert
3 Convert
4 Remove
5 Remove

All should trigger a HOLD

[Philippe Hurbain]

I started to fill in the doc, but some of my comments blow out cell size. What should be the proper way?

[Gerald Lasser]

I started to fill in the doc, but some of my comments blow out cell size. What should be the proper way?

Linewrap is making it look fine again.

[Philippe Hurbain]

OK... for some reason it didn't wrap for me, even after a reload. Works fine now.

[Willy Tschager]

Since there a almost 80 position I suggest to work on them in a block of five. So the question is should these trigger a HOLD vote or just a WARNING (comment)?

1    ERROR    Embedded POV Code found.    HOLD 
2    ERROR    '0 WRITE' found. - HOLD 
3    ERROR    '0 BFC CERTIFY INVERTNEXT' found.    HOLD 
4    ERROR    '0 ROTATION' found.    HOLD 
5    ERROR    '0 COLOR' found.    HOLD

I further suggest that if a part gets certified with non resolved warnings those should be documented by a simple comment in the part itself.

w.

If there isn't any new input I move forward to the next block.

w.

[Max Martin Richter]

Since there a almost 80 position I suggest to work on them in a block of five. So the question is should these trigger a HOLD vote or just a WARNING (comment)?

1    ERROR    Embedded POV Code found.    HOLD 
2    ERROR    '0 WRITE' found. - HOLD 
3    ERROR    '0 BFC CERTIFY INVERTNEXT' found.    HOLD 
4    ERROR    '0 ROTATION' found.    HOLD 
5    ERROR    '0 COLOR' found.    HOLD

I further suggest that if a part gets certified with non resolved warnings those should be documented by a simple comment in the part itself.

w.

If there isn't any new input I move forward to the next block.

w.

I'll comment in the document in a few days when I finished working for this year. ;-)
Please feel free to move forward, cause my thoughts to the first 5 points are very similiar to Philo's.

[Willy Tschager]

Next bunch:

6    ERROR    Incorrect use of only '0' for comments. Should be '0 //' instead.
7    ERROR    Not all used colors in LDConfig.ldr.    HOLD
8    ERROR    Matrix all zero found.    HOLD
9    ERROR    Identical vertices found.    HOLD
10    ERROR    Colinear vertices found.    HOLD

[Willy Tschager]

> 6    ERROR    Incorrect use of only '0' for comments. Should be '0 //' instead.

Should produce a warning - obviously nothing else: http://www.ldraw.org/article/218.html#lt0

7    ERROR    Not all used colors in LDConfig.ldr.    HOLD

A HOLD is too strict because of the direct color: http://www.ldraw.org/article/218.html#colours

8    ERROR    Matrix all zero found.    HOLD
9    ERROR    Identical vertices found.    HOLD
10  ERROR  Colinear vertices found.    HOLD

Agree.

w.

[Philippe Hurbain]

6 - Change to 0 // style comment. Empty line if only 0 and nothing behind
7 - Prompt user. Must allow direct colors for patterned parts or stickers.
8 - Prompt. Can be auto-corrected for flat primitives, but there is 50% chance of wrong BFC
9 - If type 2 or 3, auto correct (delete line). If type 4 and concerns two consecutive vertices, convert to type 3, otherwise prompt. If type 5 and first two vertices the same, delete line, otherwise prompt.
10 - If type 4: split into 2 triangles, otherwise prompt

[Travis Cobbs]

Bear in mind that direct colours are only allowed for pattern and sticker geometry:

http://www.ldraw.org/article/512.html#colours

So it's still not allowed in (for example) shortcuts.

[Philippe Hurbain]

Bear in mind that direct colours are only allowed for pattern and sticker geometry:

http://www.ldraw.org/article/512.html#colours

So it's still not allowed in (for example) shortcuts.

Indeed. Edited my message above for more precision.

[Willy Tschager]

Next bunch:

6    ERROR    Incorrect use of only '0' for comments. Should be '0 //' instead.
7    ERROR    Not all used colors in LDConfig.ldr.    HOLD
8    ERROR    Matrix all zero found.    HOLD
9    ERROR    Identical vertices found.    HOLD
10    ERROR    Colinear vertices found.    HOLD

Any more opinions on this?

w.

[Willy Tschager]

Here we go:

11    ERROR    Bad Vertex Sequence found.    HOLD
12    ERROR    Concave quads found.    HOLD
13    ERROR    Coplanarity.    HOLD
14    ERROR    Incorrect color for linetype.    HOLD
15    ERROR    Loop in reference found.    HOLD

[Willy Tschager]

Here we go:

11    ERROR    Bad Vertex Sequence found.    HOLD
12    ERROR    Concave quads found.    HOLD
13    ERROR    Coplanarity.    HOLD
14    ERROR    Incorrect color for linetype.    HOLD
15    ERROR    Loop in reference found.    HOLD

11 Autocorrect
12 Prompt user
13 Prompt user
14 Prompt user (guess this is about 16 for edges or 24 for triangles, quads, prims)
15 Prompt user

[Orion Pobursky]

Here we go:

11    ERROR    Bad Vertex Sequence found.    HOLD
12    ERROR    Concave quads found.    HOLD
13    ERROR    Coplanarity.    HOLD
14    ERROR    Incorrect color for linetype.    HOLD
15    ERROR    Loop in reference found.    HOLD

11 Autocorrect
12 Prompt user
13 Prompt user
14 Prompt user (guess this is about 16 for edges or 24 for triangles, quads, prims)
15 Prompt user

12 can be auto-correct (via split into triangles) as well. 
13 can be auto-corrected but the user should be warned

[Philippe Hurbain]

11 - Prompt. Any auto correction could result in wrong BFC
12 - Split into two triangles
13 - Prompt. At first sight, can be solved by splitting into two triangles, but can mess up condlines
14 - Autocorrect. Type 2 or 5 must be color 24, type 1, 3 or 4 in color 24 must be changed to color 16
15 - Prompt.

[Willy Tschager]

11 Autocorrect
12 Prompt user
13 Prompt user
14 Prompt user (guess this is about 16 for edges or 24 for triangles, quads, prims)
15 Prompt user

12 can be auto-correct (via split into triangles) as well. 
13 can be auto-corrected but the user should be warned

12 Sure, but there are always two ways to split it and I'd like to have control of it.

[Philippe Hurbain]

No, there is only one way of splitting a concave quad!

[Willy Tschager]

No, there is only one way of splitting a concave quad!

Upps! Had coplanar quad in mind.

[Orion Pobursky]

No, there is only one way of splitting a concave quad!

Yup. LDDP does this if asked.

[Orion Pobursky]

11 - Prompt. Any auto correction could result in wrong BFC
12 - Split into two triangles
13 - Prompt. At first sight, can be solved by splitting into two triangles, but can mess up condlines
14 - Autocorrect. Type 2 or 5 must be color 24, type 1, 3 or 4 in color 24 must be changed to color 16
15 - Prompt.

For 13, what you mentioned and the fact that if the quad is very non-coplainer then it should probably be fixed and not just split.

[Willy Tschager]

Here we go:

11    ERROR    Bad Vertex Sequence found.    HOLD
12    ERROR    Concave quads found.    HOLD
13    ERROR    Coplanarity.    HOLD
14    ERROR    Incorrect color for linetype.    HOLD
15    ERROR    Loop in reference found.    HOLD

Are we done with these?

w.

[Willy Tschager]

Your turn:

16    ERROR    Double lines found.    HOLD
17    WARNING    Maybe wrong color for sticker used.
18    ERROR    Length of part description.    HOLD
19    WARNING    Maybe leading spaces in part description.
20    ERROR    Keywords entry length.

[Orion Pobursky]

Your turn:

16    ERROR    Double lines found.    HOLD
17    WARNING    Maybe wrong color for sticker used.
18    ERROR    Length of part description.    HOLD
19    WARNING    Maybe leading spaces in part description.
20    ERROR    Keywords entry length.

I can't find anything in the spec that forbids 18,19,20. 19 maybe warn but programs should strip these leading spaces anyway.

[Orion Pobursky]

Your turn:

16    ERROR    Double lines found.    HOLD
17    WARNING    Maybe wrong color for sticker used.
18    ERROR    Length of part description.    HOLD
19    WARNING    Maybe leading spaces in part description.
20    ERROR    Keywords entry length.

I can't find anything in the spec that forbids 18,19,20. 19 maybe warn but programs should strip these leading spaces anyway.

Strike that for 20. Keyword line length is spec'd to 80 chars max. I think we should revised the spec to remove this requirement.

[Santeri Piippo]

Agreed. This is going to get real confusing if we do this in a forum thread.

I did the frame work for it, let me know if you can access & edit
https://docs.google.com/spreadsheets/d/1...sp=sharing

Thinking about this in the context of the part verifier: how does "prompt" go over? The part verifier says that "sorry but there's this and this issue in the part, do you want me to try to fix these"?

And regarding potential PT integration: should the PT try to prompt anything or just reject the part if such problems exist and call it a day? It needs rework anyway at that point so IMO it can't be ready for PT in that case.

[Willy Tschager]

I did the frame work for it, let me know if you can access & edit
https://docs.google.com/spreadsheets/d/1...sp=sharing

Thinking about this in the context of the part verifier: how does "prompt" go over? The part verifier says that "sorry but there's this and this issue in the part, do you want me to try to fix these"?

And regarding potential PT integration: should the PT try to prompt anything or just reject the part if such problems exist and call it a day? It needs rework anyway at that point so IMO it can't be ready for PT in that case.

Well. I'd say it the verifier is able to fix it the part should be fixed. Otherwise it would just reject by telling what has triggered the error. Period.

w.