Some examples to illustrate. I don't think Andre will have problems finding tasks for this. But again, if the top priority, WMF lead projects are well covered then we can help and involve others e.g. interesting extensions.

On 01/17/2013 09:54 AM, Chris McMahon wrote: In a positive way. ;) If after every week sprint a group gets one contributor more, then the chances of having a better next sprint will increase. Following the proposal, we don't need formal MediaWiki groups start turning the wheel. With Chris, Andre, Zeljko and Valerie we have enough to push the cycles. Of course each activity will need to have participants, and these participants might be interested in staying in touch, discuss and plan other tasks. This is where the groups might help to coordinate and generate better week sprints. I haven't been around long enough, but one problem we seem to have is that even successful activities leave little heritage for future events. Apart from the people continuously engaged e.g. through this list, it's almost like we are starting from scratch every time. Hopefully the groups will help bridging activities and growing continuously. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/**User:Qgil<http://www.mediawiki.org/wiki/… ______________________________**_________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.…

You are already planning a bug day around what I called Rotten bugs (are you ok with the name?) :) It doesn't need to be the Big Bug Day. We can start agreeing the goals... tomorrow? Then work on whatever preparations and outreach are needed, encourage some DIY tasks, be available on IRC and organize the Day for... Thursday 24?

Andre and Valerie. Note that much of the backlog for automated tests is the result of fixed BZ tickets http://www.mediawiki.org/wiki/Qa/test_backlog. Fixed bugs are great candidates for regression tests because a) what broke once is more likely to break again and b) an issue fixed may indicate more issues in nearby areas of the feature. Our UploadWizard test is a great example of a single test catching multiple issues in the same area over time.

So a mechanism by which fixed browser bugs become entered in the automated browser test backlog would be a fine thing.

If we serve paella every week in a timely manner, people will come. If they enjoyed it they will repeat another week, bringing more guests.

On 01/16/2013 02:25 PM, Quim Gil wrote: I just had a chat with Siebrand from the Language Engineering Team. They like the idea and they have specific proposals for all the weeks: http://etherpad.wikimedia.org/test-bug-i18n They are ready to start. Next week. So... why not? I will only look at the first week now (features testing). Their proposals are based on wiki pages that are pretty much ready for testers, even newcomers without much prior experience: Week 1: manual testing (Chris) * https://www.mediawiki.org/wiki/Milkshake/Manual_testing -- can be tested for each language. Reports to bugzilla. * https://www.mediawiki.org/wiki/VisualEditor/Typing/General -- can be tested for every language. Reports to bugzilla. * https://www.mediawiki.org/wiki/VisualEditor/Typing/Right-to-left -- can be tested for Hebrew. Needs one tester. Reports to bugzilla. * https://www.mediawiki.org/wiki/VisualEditor/Typing/Indic -- can be tested for all Indic languages with some adaptations. Only Hindi at the moment. VisualEditor looks like the primary goal, having Milkshake as secondary option for whoever feels more interested. The testing is aimed primarily to people with an interest in Hindi and Hebrew. Other Indic and RTL languages welcome. And in general non-Latin scripts. We have a nice pool of potential testers in the Wikipedias of those languages. Through ambassadors and community portals (and central notice? too soon/fast?) we could reach whoever we decide to reach. Of course we can do further outreach, but the Wikipedias alone should already provide the critical mass of contributors, right? Then we need to define the right environment for testing. Is it a fresh install in Labs? Something else? The wiki pages above already provide DIY testing cases. Together with https://www.mediawiki.org/wiki/How_to_report_a_bug we have the basics for the people willing to start contributing before the sprint. The sprint could be on Thursday, starting in Asian friendly times since this is where most of the potential testers will be based. We need to define if there is going to be a specific activity during the sprint, or if it's only a certain time-frame where full support will be provided to testers by the Language Engineering team. For instance, we could open the sprint with a hangout-screencast where someone goes briefly through the tests described. All the better if the demoers are a native Hindi speaker, a native Hebrew speaker, etc. There is potential for screencasts and chat rooms in those languages as well... I guess the goal would be to reach confidence in specific languages / scripts. If not confidence that it works well at least confidence that the issues are now reported as bugs. The incentive could be priority for Wikipedia in-your-language to be part of the next VisualEditor deployment: "Hi, we plan to deploy the next version of VisualEditor in your Wikipedia in two weeks, or as soon as we have the related documentation translated (link). The testing sprint some of the contributors of this Wikipedia made just gave us the confidence to include you in our Alpha deployment. Thank you everybody!" I think we can do it (with some adrenaline - good). -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

To the best of my knowledge the only publicly accessible page for VE exists at http://www.mediawiki.org/wiki/VisualEditor:Test, and I believe one might have to have special rights to edit that page.

That is a good point. But even more important is to decide what is the testing environment.

If next week is too soon and the datacenter migration complicates things, then we should be able to do this the other week. I hope there wouldn't be any reason to delay further. And that would fit the slot of Jan 30 that was left empty by Echo.

* https://www.mediawiki.org/wiki/VisualEditor/Typing/Indic -- can be tested for all Indic languages with some adaptations. Only Hindi at the moment.

https://www.mediawiki.org/**wiki/QA/Weekly_goals<https://www.mediawiki.o…

This proposal got a basic agreement and is being implemented at https://www.mediawiki.org/**wiki/QA/Weekly_goals<https://www.mediawiki.o… A rough start is expected in the first iteration of the four areas but we hope to have improvements every week. Get involved! Development teams: your proposals for testing & bug management weekly goals are welcome. On 01/16/2013 02:25 PM, Quim Gil wrote: -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/**User:Qgil<http://www.mediawiki.org/wiki/… ______________________________**_________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.…

* how to read, understand and analyze results in the Jenkins system we A good proposal, booked for the week starting on Mar 11. Please help defining what could be the practice, the actual contribution made by participants at the end of the week.