Parts Requestor System Requirements


Parts Requestor System Requirements
#1
Yes - let's collect requirements here. Then I can build a web interface as part of the Parts Tracker. It should be linked to the Parts Tracker to facilitate automatic removal when an unofficial version gets submitted. There is Parts Tracker functionality that can be re-purposed for this.

Questions:
- Should each user have a limit on how many parts than can have on their "I request this" list?
- Should each user have a limited number of "I support this votes"?
- Should there be a hierarchy of votes (Urgent/Important/Useful/Nice to have)

LDraw Parts Request System Requirements:
- page listing requested parts (sortable by part number, description, vote tally), linking to
- page for each requested part, containing
- link to part image (peeron/Bricklink/personal URL)
- username of requestor
- usernames of supporters
- username of volunteer author
- comments/activity log (like on the Parts Tracker)
- links for "I support this", "I am authoring this", "Comment"

- page listing (for current user) of requested and supported parts

- admin functionality to edit/rename/delete entries

Chris
Chris (LDraw Parts Library Admin)
Reply
Re: Parts Requestor System Requirements
#2
Chris Dee Wrote:
-------------------------------------------------------
> Questions:
> - Should each user have a limit on how many parts
> than can have on their "I request this" list?
> - Should each user have a limited number of "I
> support this votes"?

I don't see a good reason to limit either of these. If someone get out of hand we can just politely ask them to stop.

> - Should there be a hierarchy of votes
> (Urgent/Important/Useful/Nice to have)

I'm neutral on this.

> LDraw Parts Request System Requirements:
> - page listing requested parts (sortable by part
> number, description, vote tally), linking to
> - page for each requested part, containing
> - link to part image
> (peeron/Bricklink/personal URL)
> - username of requestor
> - usernames of supporters
> - username of volunteer author
> - comments/activity log (like on the Parts
> Tracker)
> - links for "I support this", "I am authoring
> this", "Comment"
>
> - page listing (for current user) of requested and
> supported parts
>
> - admin functionality to edit/rename/delete
> entries

All this looks good and I can't think of anything to add.
Reply
Re: Parts Requestor System Requirements
#3
Chris Dee Wrote:
-------------------------------------------------------
> Questions:
> - Should each user have a limit on how many parts
> than can have on their "I request this" list?
> - Should each user have a limited number of "I
> support this votes"?

No, it's a wishlist with no obligation.

> - Should there be a hierarchy of votes
> (Urgent/Important/Useful/Nice to have)

No opinion but why not. On the otherside: Light is beautiful.

> LDraw Parts Request System Requirements:
> - page listing requested parts (sortable by part
> number, description, vote tally), linking to
> - page for each requested part, containing
> - link to part image
> (peeron/Bricklink/personal URL)
> - username of requestor
> - usernames of supporters
> - username of volunteer author
> - comments/activity log (like on the Parts
> Tracker)
> - links for "I support this", "I am authoring
> this", "Comment"
>
> - page listing (for current user) of requested and
> supported parts
>
> - admin functionality to edit/rename/delete
> entries

Wow! If it is doable why not. Important thing is that is going up fast. Additions can be made later.

w.
LEGO ergo sum
Reply
Re: Parts Requestor System Requirements
#4
Chris,

is this in the made? How long it will take to go live? I'm questioning this 'cos there are continuously popping up part request and we have to rule them somehow. If building will take I'd propose to post the simple system and work with it 'til the PRS is in place.

w.
LEGO ergo sum
Reply
Re: Parts Requestor System Requirements
#5
It would be good to get input on the requirements from the other SteerCo members. Kevin? Scott?

It has not got beyond the design stage yet.

Is this more important that a web submission interface for the OMR?

Chris
Chris (LDraw Parts Library Admin)
Reply
Re: Parts Requestor System Requirements
#6
My opinion is to do what you are most interested in doing first. I'd prefer the Parts Requester System, but if I were you, I'd do what I want most.

Scott
Reply
Re: Parts Requestor System Requirements
#7
Chris Dee Wrote:
-------------------------------------------------------
> Is this more important that a web submission
> interface for the OMR?

No. BTW looks like we have to kick some asses around.

w.
LEGO ergo sum
Reply
Re: Parts Requestor System Requirements
#8
This topic is now moved for general discussion
Reply
Re: Parts Requestor System Requirements
#9
Thanks for publishing this.

Here's my small opinion on this:

> Should each user have a limit on how many parts than can have on their "I request this" list?
> Should each user have a limited number of "I support this votes"?

I think: "yes, there should be a limit", because I fear 2 negative effects otherwise:
(a) unequality: a user posting 100 "want" votes will more probably get his part through than a user who just needs 1 part.
(b) loss of focus: spilling out just many "want" votes will not focus us onto the parts really needed.
Would we limit the number of "want" votes to, say, 10, then the users themselves will see
that workforce is limited, and that they cannot demand just tons of parts.
Instead, they have to decide which 10 ones are the most urgent ones,
and after these parts have been created, they can place them again.
For the reason of (a), I also ask that a user might place his 10 votes all on one part he needs very urgently,
or distribute them otherwise, like, say 5+2+2+1.

> Should there be a hierarchy of votes (Urgent/Important/Useful/Nice to have)

I think that would make things just complicated and difficult to track.
I wouldn't need that.

> LDraw Parts Request System Requirements

My suggestion would be: keep things as simple as possible.

> - page listing requested parts (sortable by part number, description, vote tally), linking to
> - page for each requested part, containing
> - link to part image (peeron/Bricklink/personal URL)
> - username of requestor
> - usernames of supporters
> - username of volunteer author
> - comments/activity log (like on the Parts Tracker)
> - links for "I support this", "I am authoring this", "Comment"
> - page listing (for current user) of requested and supported parts
>- admin functionality to edit/rename/delete entries

This would be the "gold" implementation, and if it could be done, of course be well appreciated here.
For me, much less already would suffice, for example a Wiki table where people can edit collectively
their requests. A simple script could check that no one places more than his allowed number of votes.
People could simply enter their vote count into a table cell.
However, that of course would be an intermediary solution until the "gold" one is possible.
I just fear that the "gold" one takes quite an amount of work.
Or can some structures from the existing PT be copied+pasted?
For example, the "wish" list in fact is very similar to the "parts" list,
and the "wish" activity is very similar to the "PT activity",
and the "wish status" is very similar to the "part status" etc.pp.

Would I get asked if this more needed than a OMR, then I personally would answer "yes".

best,
Steffen
Reply
Re: Parts Requestor System Requirements
#10
I agree with Steffen, a limit on number of support votes would be great to avoid flooding, and make really needed parts stand up. But how do users refill their votes quota? After some time? Or do they get back votes they cast on a part when this part is done?
Reply
Re: Parts Requestor System Requirements
#11
I think users should at any point of time be able to rearrange their votes as they like.

Thus, when a part is completed, it is removed from the wishlist, and they have back their votes automatically.

But also at any point of time, they should be able to rearrange their votes.

The simplest thing would be to let a user enter his number of votes to a part numerically.
Setting it to 0 means removing the vote(s) for a certain part.
The sum simply must not exceed a given limit.

The more I think it over, I even find that even a limit of 10 is too high.
Maybe be very restrictive and choose 5 or so.
The number must reflect the limited workforce we have.
Users need to experience that they need to explicitly decide where to put it, IMHO.
Reply
Re: Parts Requestor System Requirements
#13
I'm with you two. It's better to know the 'most needed' parts and optional assignment of votes is the best way to do this. Someone could put all their votes on one part if it's really needed.

Tim
Reply
Re: Parts Requestor System Requirements
#12
Questions:

- Should each user have a limit on how many parts than can have on their "I request this" list?

I think that 20 parts as maximum for each user is affordable.
Because I found that there are missing parts under 20 at the highest estimate when I made any official models nowadays.
20 would be sufficient number for 1 or 3 models and we should share our opportunity with others with fairness.
It would be good if the requested part was done, then the user can request another part as many as 20.


- Should each user have a limited number of "I support this votes"?

I think that this option could be eliminated.
We can find the highest group by collecting each user's request lists by Q1.


- Should there be a hierarchy of votes (Urgent/Important/Useful/Nice to have)

It might be good but have curious practicality.
Because people could vote on every part they want as urgent and we can't identify which part is really urgent.
In my opinion, all we need is Q1.


LDraw Parts Request System Requirements:

What I mentioned above is just an answer for predetermined questions.
If you don't mind, I would like to suggest what I have in mind regarding LDraw Part Request System in different view points.

First of all, I really appreciated to all part authors who have made each LDraw part over 5,000 until now. It's amazing!
By your favor, I could have enjoyed to make over 100 official LEGO products by LEGO CAD including very big model in various theme like starwars UCS, modular buildings, 8110, etc.
I have used SR3D Builder as a main program and MLCAD for flexible parts.

In my experience, I found a group of missing parts almost whenever I made official models.
This is the reason why you have found my requests on the previous part request thread so frequently.

Frankly speaking, I had just asked one or two parts at once, even though I had needed a group of missing parts to make the model complete, because I know the part authoring is very hard.
I think that it might be the reason why many user also hesitate to ask many parts at once and it's the why we have so many products that we couldn't make it complete yet, even though we have over 5,000 parts.
The point is that, to satisfy user's request and to manage missing part problem simultaneously, we should think the group of missing part to make the real LEGO product complete in my opinion.

We have abundant resources to reference nowadays including peeron or bricklink inventory for each LEGO product.
So we could get the list of missing parts and the product numbers imperfect to make in CAD automatically by just making a program to compare the list of LDraw parts with one of peeron or bricklink inventory according to the product number.
What I mean is that we don't need to ask LDraw user what the missing parts are.

So I would like to suggest why don't you give LDraw users the list of imperfect LEGO product and ask them which product they mostly want to make complete by CAD.
If many part authors concentrated on a group of missing parts at once in specific LEGO product based on the request which users mostly want to make, we could deal with the problem of missing part more efficiently.

For fairness, we could restrict the frequency for each user, for example, once per a week or a month, if we will have large number of user requests in this forum.

Thanks for reading

KWON

p.s.
I'm not a native in English and there must many grammar errors.
I hope that you could catch my thinking without misunderstanding.
Reply
Re: Parts Requestor System Requirements
#14
Could you please give us an update on this?

w.
LEGO ergo sum
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 1 Guest(s)