Needs Work and Help

[Orion Pobursky]

For Needs work parts the header spec says:

If the part is good enough for public use, but has some deficiencies that need to be addressed, the text " (Needs Work)" (without the quotation marks) can be added to the end of the description. If the description includes "(Needs Work)", a comment must be added to the file immediately after the header that explains the work that needs to be done

However, while most parts have comments, some parts use !HELP. What standard should we enforce?

[Orion Pobursky]

Here are my thoughts:


- The contents of !HELP not rigidly defined, nor do I think it should be

- From a user perspective of having the Need Work reason in the !HELP:
 PRO: If the user notices, it will explain why a part looks the way it does.
 CON: Doesn't really explain how to use the part which is what the word help implies.

- Having the Needs Work reason in !HELP allows the PT to enforce including a reason for the Needs Work

- There are 302 files that have Needs Work. Most of those have comments and not !HELP

- I favor switching to using !HELP for all new and unofficial parts

[Gerald Lasser]

When thinking this a bit further, the !HELP is also visible in the editor, like LDCAD, and is accessible to the end user, while a comment is not.

[Chris Böhnke]

While I would prefer a more clean usage of the !HELP line, I clearly see the benefit of the "Needs Work" info appear in the header.

Without the added info this is a confusing suffix for inexperienced users. Making it more clearly visible helps (duh... ) a lot here.

Not sure how well known this is, but Stud.io uses "(Needs Work)" as well occasionally for raw parts imported via some mechanics from LDD it seems. This might confuse further if it's not clearly visible why the part has this suffix.

[Orion Pobursky]

Not sure how well known this is, but Stud.io uses "(Needs Work)" as well occasionally for raw parts imported via some mechanics from LDD it seems. This might confuse further if it's not clearly visible why the part has this suffix.

Does Stud.io support the !HELP meta? If not, I don't care since those parts aren't part of the official library.

[Peter Blomberg]

As an inexperienced user, I find the (Needs Work) confusing in the description. If a part needs work, why has it been approved into the library?

On the other hand, there are a lot of parts that would need to be updated for one reason or another; e.g. orientation, use of primitives, height of origin, etc. However, these tend to not be known at the time the part is being edited and would have to be amended to parts already in the library.

[Gerald Lasser]

As an inexperienced user, I find the (Needs Work) confusing in the description. If a part needs work, why has it been approved into the library?

On the other hand, there are a lot of parts that would need to be updated for one reason or another; e.g. orientation, use of primitives, height of origin, etc. However, these tend to not be known at the time the part is being edited and would have to be amended to parts already in the library.

A big chunk of the parts carrying the "needs work" is more or less irrelevant to the user.

If I scan the official parts, I get 271:

• around 30 concern a "missing proper fallback texture for a texmap"
  
• as Magnus mentioned, another 50 or so are stickers where a comment is there, where a dithered area has been designed in a effcicent way
  
• Many part are missing interior, which is absolutely no deal if this is a (glued/fixed) assembly, you can discuss that interior of parts that CAN be taken apart, e.g. boat parts where the connection of the hull and the deck is not designed, should keep this information (probably yes)
  
• Only a few are really "visible" to the enduser, i.e. were the outside is affected, e.g. the zip line hook 30229
  

concerning the second part of your post, orientation and origin, I would rather abstain from obsoleting parts due to their orientation, they might not fit into their realm, but that generates a lot of a/b/c versions that (however less we say we care) don'T kmatch the BL or RB descriptions/designid.
Even LEGO itselft rotates parts around, e.g. the new mudguard, 6618, is upside down compared to the others when I look at the raw mesh.

[Sylvain Sauvage]

Does Stud.io support the !HELP meta? If not, I don't care since those parts aren't part of the official library.

Studio doesn’t use the !HELP meta.  Nor does it uses a few other metas….

Also, the “(Needs Work)” in not in the description of official (for Studio) parts, because official parts use the BL descriptions.
You may encounter the mention if you import an LDD file (or an LDraw file) with parts for which Studio only has the raw conversion from LDD.
Those .dat are part of the early “let’s grab all the .dat files we can and put them in Studio, we’ll associate them to BL IDs later” stage of Studio 1.0.
Those parts are shown by Studio but have no connectivity info, no collision info, and are not associated to any BL catalogue entry.

[Philippe Hurbain]

 I would rather abstain from obsoleting parts due to their orientation, they might not fit into their realm, but that generates a lot of a/b/c versions that (however less we say we care) don'T kmatch the BL or RB descriptions/designid.

I STRONGLY agree with that! Granted, varied orientation for the same kind of part can seem weird, but version change is much, much more confusing!

[Orion Pobursky]

Thanks for the input. We will continue with the current practice.

I would rather abstain from obsoleting parts due to their orientation

I agree as will. Obsoleting should only happen for bad geometry.

[Peter Blomberg]

I would rather abstain from obsoleting parts due to their orientation, they might not fit into their realm, but that generates a lot of a/b/c versions that (however less we say we care) don'T match the BL or RB descriptions/designid.

The problem is that we are using abc both for different geometry and for replacements of undesired geometry. The latter could be better handled with versioning.
12345 version 1
12345 version 2
Now that I think of it, the former could also be implemented using "versioning" that are not intended to replace
12345
12345 variant b
We also use letters to enumerate parts of multipacks.

Getting back to the original topic; I wanted to discover some way of annotating official parts with a tag that states what would need to be fixed if a part for some other reason is being edited. IMHO, the "needs work" sounds appropriate although it is not currently used or even intended for such use.

Maybe !NEEDSWORK could be added as a meta instead of being appended to the description and/or comments/!HELP.

Why not create a !BRICKLINK meta specifically for taking care of the mapping? Or a !LINK meta with two arguments - one for the authority (e.g. BrickLink), and the other for the ID?

[Orion Pobursky]

... a !LINK meta with two arguments - one for the authority (e.g. BrickLink), and the other for the ID?

I like this idea a lot. But I think your entire comment should be spun off into it's own thread.