Open hokienick opened 7 years ago
There have been talks about breaking up UI Prototype into "Demo" and "Technical"
I'll ask @adroc-tc to chime in here.
Looks to me, that the problem is quite related to the coding standards, or even to the co-piloting standards. Everything listed by @hokienick should be just explicitly demanded in Challenge Specs. Now setup of an adequate build system is usually not requested in UI Prototype challenges, so participants have no reason to spend their time to set it up. Further in the course of a project, it is usually also not demanded to setup a build system, so in some challenges some participants automate some parts of the build the way which is easier for them, but we usually end up without any well planned build system.
Create a boilerplate for all projects, ask the users to start within a boilerplate. An automatic build/customization boilerplate that is managed in a system-wide level would help. This will create uniform starting point and drive the users to stick to the requirements better. The good side of a boilerplate that you download is the ease of use. Imagine that you come to the challenge and to get started you just download the boilerplate (already configured for the challenge when it was created), so you just start writing the code, and don't worry about your environment setup.
CAB MEETING
Working on splitting into Demos and Front End UI. This will hopefully help us start convincing customers to start using newer technologies.
Requires update in documentation. Updating review scorecards. A lot of the technology is dictated by customers.
Putting @jamesmarquez's inputs from e-mail here:
1) UI Prototype scorecard have more weight in UI than the what's in the code and its functionality. 1 minor issue in UI will cost you a point. It would be great if the code and UI have same weight. Example if the Prototype output is for Wordpress use, some submissions have class in their
tag. Usually in wordpress, these p tags are generated and we can not put class names in them, resulting to extra work for wordpress developer.
2) Another thing is the pixel perfection, 1 or 3 pixel difference should not be an issue.
3) 4 point system seems obsolete, example if 1 submission has 1 minor issue while other submission have 10 minor issue, they usually get the same score of 2. It would be great if we move to 5 point base system.
4) Reviewers have different interpretations of the questions in scorecard. Example for functionality question under UI group, some treats code issues to as UI functionality issue. It would be great if we can have Wiki or Help page explaining each questions and each should have several case examples.
5) Some reviewers only checks the UI and ignore or lightly take the other questions. It would be great if there's a way that we can make the quality of reviewing to the next level. I also think the reviewer's payment is a bit low if you do quality reviews.
cc: @adroc-tc @hokienick
at least this should be done if it can be done
I don't quite see, how a submission with 1 minor issue can get the same score as a submission with 10 minor issues with the current scorecard, if the reviewer tries to be objective? If the situation is more like submission with 6 minor issues gets the same score as the one with 8 minor issues it makes sense, and is ok, IMHO: it means two solutions have about the same quality, thus other aspects and/or submission time are fair tie-breaker. Mind that when issues are minor, counting whether a submission has 5 or 6 minor issues is highly subjective.
Minimize human involvement. Like the algo. track. It can be easily done if someone encourage +ve things.
"UI Prototype track does not follow latest and best practices in creating UI Prototypes
https://apps.topcoder.com/forums//?module=Thread&threadID=880303&start=0