Extension talk:Translate/Usability improvements 2014

Some comments
--Nemo 13:16, 18 March 2014 (UTC)
 * Please use appropriate wiki markup to make the text more structured and readable. It would also be nice to have an overview of the project in addition to the list of bugs.
 * Sometimes it's not clear what you're saying due to unclear or incorrect terminology, please familiarise yourself with Help:Extension:Translate/Glossary.
 * How did you estimate the time needed for the various bugs and how did you schedule them? The arbitrary source language bug has an additional difficulty in having a dependency on core: you should probably start working on that early, in order to have the changes to core merged when you start working on the Translate side or anyway before the project ends.


 * I echo the thirst point of Nemo. It would be good to see more notes why do you think some bugs are easy and some of the difficult. Add some of your own thoughts how you would go fixing the bugs, or if there are multiple solutions, which one you would choose based on your current understanding. For example, some of the bugs might require working on the backend with PHP, some JS and some both. Can you identify good candidates for files or classes which need modification?
 * Can you identify potential risks for each bug and how can you avoid those risks becoming true?
 * I also encourage you to work on the patches you have submitted for review to get them merged as well. --Nikerabbit (talk) 16:22, 19 March 2014 (UTC)


 * On the third point I see you added as well as some estimates of difficulty, thanks. I saw Siebrand volunteered to mentor so you'll have a great guidance for scheduling! --Nemo 09:59, 24 March 2014 (UTC)

Minimum results required
Alright, so we have a collection of bug reports selected by your mentors. Is there a common denominator among them? Have you agreed with your mentors the right sequence, just in case you don't have the time or the skills to fix them before the end of GSoC? If there is a common denominator, or if there is a task that is more important than the others, please rename your project to reflect that. "Critical bug fixes" is not an accurate description of these reports, and I would rather put the focus on the biggest item(s) right from the beginning.

Questions to you an to your mentors: what would be the scope of your very first release? what is the minimum you should complete in order to consider that this project PASSED the final GSoC evaluation?

Note that we request our candidates to define a minimum viable product, the minimum set of features that should be pushed first as a testable release. We do this to avoid a common problem of students putting a lot of time in one aspect, and then not having time enough to complete the rest, ending up with nothing that actually works. This principle cannot be applied here, since we are talking about a list of bugs, but your efforts trying to integrate this idea to your proposal are welcome. Thank you.--Qgil (talk) 23:38, 27 March 2014 (UTC)
 * I've made a few updates, including an update on the project name. siebrand (talk) 09:14, 28 March 2014 (UTC)

Mentors
Your proposal mentions that your mentors are, , and , but in Melange only Siebrand and Robin have signed up. No worries, two mentors is already very good. We just need to confirm who are the mentors backing this project.--Qgil (talk) 23:43, 27 March 2014 (UTC)
 * Robin and I will be the mentors. Neither of us have signed up as mentor for any other projects. siebrand (talk) 09:08, 28 March 2014 (UTC)

microtasks
One of the microtasks that Kunal did was 112323 (Adding Special:TrackingCategories ). This was a relatively big feature compared to what most people did for their microtasks. I think that should count in his favour. Bawolff (talk) 00:09, 31 March 2014 (UTC)