Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestions for top (summary) section, and a couple of questions #66

Open
kimadagem opened this issue May 21, 2017 · 0 comments
Open

Suggestions for top (summary) section, and a couple of questions #66

kimadagem opened this issue May 21, 2017 · 0 comments

Comments

@kimadagem
Copy link

After the thread I posted on Reddit someone messaged me about something in that section. They were planning to reply in the thread about it but in trying to find an example started to get confused so they got in touch with me instead.

I have to admit that I don't tend to look at this section too much - I'm mainly focused on the individual reviews (maybe a leftover response from the legacy site). But when I did check it out I got confused too, and ended up reorganizing it a bit to try to make it clearer for people. Here's what I came up with:

Total reviews: 4
Hourly pay: $5.93
Time to approve: 3 days
Communication/responsiveness: 2 N/A, 1 satisfied, 1 dissatisfied
Rejection reports: 0
Broken: 1
Recommended: 3 (75%)
Not recommended: 1 (25%)
TOS violations: 1

This makes all the topics stand out, and if someone wants to check something in particular - for example, rejections - they can find it easily. And it can be organized the current way, in both the 90-day and all-time sections (which incidentally my contact thought was a great idea, because they think recent data is more valuable).

About the rejections stats: I haven't had to use the "how much of your work was rejected" field on the review form but I'm a bit confused about how it's supposed to be used. Is it just for that particular hit or is it supposed to apply to all hits I've done for a requester, whether or not I've reviewed them? If it's supposed to be just for that hit then it would seem to apply only for batches. If it's for all hits from a requester, would the data in the summary sections still be consistent? I don't do batches so maybe I'm just applying "legacy site thinking" (focusing on the requester rather than the individual hit) here, but I think there are others who also do only one-off hits that might not know what to do with that field, or might use it in a way that wasn't intended.

I am also wondering if those stats should be in numbers, percentages, or both. I think both might be good for some topics - the ones I included in the example - but am thinking that using them everywhere might be too much for some people to process.

And finally - as you know, I don't code, so I have no idea how easy/hard it would be to make these changes. Some seem like just a rewording; others might be harder to implement. But the information in these summaries wasn't clear to at least one person, who took the time to contact me about it, so others might be having the same experience, and if there's a way to make it easier to read and more helpful, I thought it was worth suggesting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants