Certifiable but currently unneeded primitives


Certifiable but currently unneeded primitives
#1
Recently I've noticed that Chris has begun to hold certifiable but currently unneeded primitives (for example this one). To me, this seems like a bad idea.

According to our reference, we define a held part as:
Reference Page Wrote:Hold (No) - It's getting there, but not yet.
There are errors to be corrected before the part can be released. The author has to take care of the errors.

These parts clearly do no fall under this category. Now, I understand the sentiment of wanting to sort these parts so you don't have to look over them again and again, only to realize you don't need to deal with them/certify them now. However, by putting them on hold, your only shifting this nuisance to part authors/fixers. Imagine the part author who checks his submitted parts list to see he has a held part, but when he goes to see what's wrong and fix it, finds there is, in fact, nothing wrong with it. Furthermore, imagine someone who likes to fix up parts perusing the held parts list looking for a part to fix up, constantly clicking on parts that don't need to be fixed. It'll be both annoying and off-putting to them as well.

Therefore, I'd like to suggest creating a new category for parts like this (beyond our current "certified", "needs admin review", "needs more votes", "has uncertified subfiles", and "held" categories). You could call them "Certified but unneeded" (or something along those lines) and give it a seperate color (may I suggest blue?). This way, the parts are seperated out so both you and others can skip over them instead of having them always being in the way, and they won't be a nuisance for anybody any more.
____________________________________________________________________________________________________
I'm theJude! So that's what you call me. You know, that or, uh, his Judeness, or uh, Juder, or el Juderino if you're not into the whole brevity thing.
Reply
Re: Certifiable but currently unneeded primitives
#2
I fully understand your concern in this case. As long as I am in this community, this is the normal procedure for unused files.
Your idea has a good point, but left another one.
The good one: if i see i do not need to care about that file i am quicker in searching parts that needs attention.
The bad one: once the part was checked it wasn't checked in context.

If I remember right, in the very first days those files have been just deleted from PT.

Standard primitives can be recreated by application like Edger2. Special geometry primitives might do not fit anywhere else.

The more i think about all aspects - I think those files should be deleted.
Reply
Re: Certifiable but currently unneeded primitives
#3
I created some of these "unneeded" prims in the past, because after the upload of the main file I got some suggestions to change this and that. And therefore I substitute these prims with other shapes. Now they are filling the PT. :-(
In my eyes all these files should be deleted.
/Max
Reply
Re: Certifiable but currently unneeded primitives
#4
I agree with Jude that voting hold for unused primitives is a very, very bad idea,
and I was a little frightened to see this happen on the PT.

Let me explain why.

Of course, the intention is good: keeping unneeded primitives from going out officially and cluttering the library. BUT: the PT release procedure already includes afaik a mechanism for that: It will only release a primitive if it is a fix for an already official one OR is a new one being used by a file to be released.

Now this mechanism has been superimposed by a second, manual one, which is redundant,
trying to achive the same effect. With bad consequences:

when a part author uses one of the unofficial primitives, his part, even when admin-certified,
will never get official because the held primitive prevents that.
he has to manually contact the pt admin by email to make him remove the hold vote.
and this has to be done for each and every file by each and every part author submitting.
many will forget that email, and their parts will drown in the "has uncertified subfiles" section of the parts list.
The previous technique was so simple and elegant! I cannot see why this had to be replaced by this brute-force and tedious,
communication-intensive, error-prone idea.

The situation has even be worsened now by other people than the pt admin, voting hold as well
for such primitives. Now those people need to be contacted as well by part authors.
they sometimes even do not have mail adresses of the hold voter.

This is all a mess. A good idea gone terribly mad.

I would like to strongly suggest to reconsider here.
Remove the hold votes on unused primitives.
Even review and certify and admin-certify them as desired.
And keep the previous technique of only releasing primitives which were already official or are really used by at least 1 file released.
So simple. So practical. So well-established. Functioning for >10 years this way now. Keep.
Reply
Re: Certifiable but currently unneeded primitives
#5
I fully agree with Steffen here but would like to add something a bit off-topic:

Steffen Wrote:The situation has even be worsened now by other people than the pt admin, voting hold as well
for such primitives. Now those people need to be contacted as well by part authors.
they sometimes even do not have mail adresses of the hold voter.
perhaps we could have a "send a reminder" link or so for hold votes? During my absence I didn't have time for ldraw and mostly ignored the PT's update emails since they most often contain people voting cert/novote/hold on parts I gave a cert/novote on. I took to note a couple of my hold votes were left dead in the PT. Now if I had gotten a more straight-to-the-point email "X requests your attention to your hold vote on 12345.dat", that would've gotten my attention more easily.

And then it turns out that this problem persists even now, a couple of my hold votes about moved-to-refs had been corrected and Steffen had to post a vote in an unrelated part (44937) to catch my attention on that... so yeah.
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 1 Guest(s)