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
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