On 12/14/2012 02:17 PM, Chris McMahon wrote:
2. Decide a mobile area to focus, a way to run the sprint and a date for it. Define also the goals and how to measure the success of the sprint.I'm on board too, but I would like to suggest that Michelle spearhead this activity.
She seems to be busy...
I can put time organizing the event and promoting it but there is a key aspect YOU (defaulting to Michelle / Maryana?) need to decide:
- What problem do we want to solve with this activity?
Once this is clear then we can answer better how, wen and who exactly must be there doing what.
..."a way to run the sprint" is the tricky part. I think there are basically two options: synchronous and asynchronous. Synchronous is arguably more difficult, so lets' talk about that option first...
Synchronous test event: we did this successfully for AFTv5. Here is the test plan that I used: http://www.mediawiki.org/wiki/QA/Article_Feedback_Test_Plan . That test plan is based on ideas from "Session Based Test Management", http://en.wikipedia.org/wiki/Session-based_testing (Just btw, the software testing articles on enwiki are pretty awful, someday I'd like to clean them all up, but it's a big job)
I borrowed a lot of details for synchronous test events from the Weekend Testing Americas group. They found some time ago that Saturdays from 10AM-1PM Pacific time is generally more successful than other times. We had a dedicated test environment and an irc channel. Everyone worked at the same time and collaborated on IRC simultaneously, and it was more fun than you might imagine.
Asynchronous test event: For a period of time (a day? a week?) I'm not sure...) everyone participating is testing on their own, pending whatever collaboration they can create among themselves I guess. I think a test plan with "charters" would be required for an async test event, as well as a coordinator to field information, feedback, questions, etc. from participants. I think Yuvi has done this before for mobile, but I don't know any details.
Again, without deciding the problem we want to solve it is difficult to find the perfect answer to this.
In general I think an approach like this could work:
* We have one big goal and then other little goals related.
* Each goal has some tasks defined.
* Some of the tasks can be started and eventually completed by anybody anywhere. We open the gates for those asap, identifying who can help volunteers here and on IRC.
* As the sprint day approaches we can see what hard nuts haven't been solved yet, what tasks benefit from synchronous collaboration.
* The goals of the sprint day (end eventually the agenda, if any is needed) will be come clear as the date approaches.
* Then the sprint day is today and we all do our best.
* After that some of us still need to have energy and time in the following days to process the useful data in the relevant wiki pages, write the blog post and close the activity properly.
On Tue, Dec 18, 2012 at 11:31 AM, Quim Gil qgil@wikimedia.org wrote:
On 12/14/2012 02:17 PM, Chris McMahon wrote:
2. Decide a mobile area to focus, a way to run the sprint and a date for it. Define also the goals and how to measure the success of the sprint.I'm on board too, but I would like to suggest that Michelle spearhead this activity.
She seems to be busy...
I can put time organizing the event and promoting it but there is a key aspect YOU (defaulting to Michelle / Maryana?) need to decide:
- What problem do we want to solve with this activity?
I have some suggestions :)
I'd like for us to leverage our editing community to test out contributory features, so we can figure out where in the browser/device matrix our new experimental features (like editing, image uploads, and watchlists) break down, and whether they do so gracefully or not. In the early part of 2013, the mobile team is going to be especially focused on image uploads to meet our goal of 1,000 unique uploaders per month on mobile, so it makes sense to focus the most attention there.
In order to have a productive sprint, I'm guessing we'd need to host this session sometime in late January/February, to give the dev team time to iron out the obvious bugs and move contributory features from alpha/beta to production.
So that gives us some time to mull over the framework, decide if we want to go the synchronous/asynchronous route, do outreach, etc. :) Why don't we revisit this discussion in early January, after our next big release of features, when we'll have a bit more clarity on the product side?
M
Once this is clear then we can answer better how, wen and who exactly must be there doing what.
..."a way to run the sprint" is the tricky part. I think there are
basically two options: synchronous and asynchronous. Synchronous is arguably more difficult, so lets' talk about that option first...
Synchronous test event: we did this successfully for AFTv5. Here is the test plan that I used: http://www.mediawiki.org/wiki/**QA/Article_Feedback_Test_Planhttp://www.mediawiki.org/wiki/QA/Article_Feedback_Test_Plan. That test plan is based on ideas from "Session Based Test Management", http://en.wikipedia.org/wiki/**Session-based_testinghttp://en.wikipedia.org/wiki/Session-based_testing(Just btw, the software testing articles on enwiki are pretty awful, someday I'd like to clean them all up, but it's a big job)
I borrowed a lot of details for synchronous test events from the Weekend Testing Americas group. They found some time ago that Saturdays from 10AM-1PM Pacific time is generally more successful than other times. We had a dedicated test environment and an irc channel. Everyone worked at the same time and collaborated on IRC simultaneously, and it was more fun than you might imagine.
Asynchronous test event: For a period of time (a day? a week?) I'm not sure...) everyone participating is testing on their own, pending whatever collaboration they can create among themselves I guess. I think a test plan with "charters" would be required for an async test event, as well as a coordinator to field information, feedback, questions, etc. from participants. I think Yuvi has done this before for mobile, but I don't know any details.
Again, without deciding the problem we want to solve it is difficult to find the perfect answer to this.
In general I think an approach like this could work:
We have one big goal and then other little goals related.
Each goal has some tasks defined.
Some of the tasks can be started and eventually completed by anybody
anywhere. We open the gates for those asap, identifying who can help volunteers here and on IRC.
- As the sprint day approaches we can see what hard nuts haven't been
solved yet, what tasks benefit from synchronous collaboration.
- The goals of the sprint day (end eventually the agenda, if any is
needed) will be come clear as the date approaches.
Then the sprint day is today and we all do our best.
After that some of us still need to have energy and time in the
following days to process the useful data in the relevant wiki pages, write the blog post and close the activity properly.
-- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/**User:Qgilhttp://www.mediawiki.org/wiki/User:Qgil
+1 with Maryana. I was going to also ask that we focus on the photo upload features, their usability and functionality given our more recent sprints have been focused on these features. I'll work with Maryana to create goals, guidance and ways to measure our success as well as ways to solicit feedback for improving the experience in the feature.
On Tue, Dec 18, 2012 at 1:11 PM, Maryana Pinchuk mpinchuk@wikimedia.orgwrote:
On Tue, Dec 18, 2012 at 11:31 AM, Quim Gil qgil@wikimedia.org wrote:
On 12/14/2012 02:17 PM, Chris McMahon wrote:
2. Decide a mobile area to focus, a way to run the sprint and a date for it. Define also the goals and how to measure the success of the sprint.I'm on board too, but I would like to suggest that Michelle spearhead this activity.
She seems to be busy...
I can put time organizing the event and promoting it but there is a key aspect YOU (defaulting to Michelle / Maryana?) need to decide:
- What problem do we want to solve with this activity?
I have some suggestions :)
I'd like for us to leverage our editing community to test out contributory features, so we can figure out where in the browser/device matrix our new experimental features (like editing, image uploads, and watchlists) break down, and whether they do so gracefully or not. In the early part of 2013, the mobile team is going to be especially focused on image uploads to meet our goal of 1,000 unique uploaders per month on mobile, so it makes sense to focus the most attention there.
In order to have a productive sprint, I'm guessing we'd need to host this session sometime in late January/February, to give the dev team time to iron out the obvious bugs and move contributory features from alpha/beta to production.
So that gives us some time to mull over the framework, decide if we want to go the synchronous/asynchronous route, do outreach, etc. :) Why don't we revisit this discussion in early January, after our next big release of features, when we'll have a bit more clarity on the product side?
M
Once this is clear then we can answer better how, wen and who exactly must be there doing what.
..."a way to run the sprint" is the tricky part. I think there are
basically two options: synchronous and asynchronous. Synchronous is arguably more difficult, so lets' talk about that option first...
Synchronous test event: we did this successfully for AFTv5. Here is the test plan that I used: http://www.mediawiki.org/wiki/**QA/Article_Feedback_Test_Planhttp://www.mediawiki.org/wiki/QA/Article_Feedback_Test_Plan. That test plan is based on ideas from "Session Based Test Management", http://en.wikipedia.org/wiki/**Session-based_testinghttp://en.wikipedia.org/wiki/Session-based_testing(Just btw, the software testing articles on enwiki are pretty awful, someday I'd like to clean them all up, but it's a big job)
I borrowed a lot of details for synchronous test events from the Weekend Testing Americas group. They found some time ago that Saturdays from 10AM-1PM Pacific time is generally more successful than other times. We had a dedicated test environment and an irc channel. Everyone worked at the same time and collaborated on IRC simultaneously, and it was more fun than you might imagine.
Asynchronous test event: For a period of time (a day? a week?) I'm not sure...) everyone participating is testing on their own, pending whatever collaboration they can create among themselves I guess. I think a test plan with "charters" would be required for an async test event, as well as a coordinator to field information, feedback, questions, etc. from participants. I think Yuvi has done this before for mobile, but I don't know any details.
Again, without deciding the problem we want to solve it is difficult to find the perfect answer to this.
In general I think an approach like this could work:
We have one big goal and then other little goals related.
Each goal has some tasks defined.
Some of the tasks can be started and eventually completed by anybody
anywhere. We open the gates for those asap, identifying who can help volunteers here and on IRC.
- As the sprint day approaches we can see what hard nuts haven't been
solved yet, what tasks benefit from synchronous collaboration.
- The goals of the sprint day (end eventually the agenda, if any is
needed) will be come clear as the date approaches.
Then the sprint day is today and we all do our best.
After that some of us still need to have energy and time in the
following days to process the useful data in the relevant wiki pages, write the blog post and close the activity properly.
-- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/**User:Qgilhttp://www.mediawiki.org/wiki/User:Qgil
-- Maryana Pinchuk Associate Product Manager, Wikimedia Foundation wikimediafoundation.org
A month later... :)
Can we agree on a slot for a mobile testing activity at
https://www.mediawiki.org/wiki/QA/Weekly_goals ?
As far as I know we still don't have a candidate confirmed for the week of Feb 11 on browser / automated / regression testing. Otherwise the next features / prospective / manual testing week starts on Feb 25.
We can start with a small goal for the week selected, requiring a preparation bringing little overhead to you. Once the goal is defined then we can help preparing the week and handling it. The point of this QA support is precisely to save you work, not to bring you more.
Please consider. If you do have a topic but for some reason you prefer to have it on a later date please let us know as well, and we will book a slot for it.
Thank you!
On 12/18/2012 11:03 PM, Michelle Grover wrote:
+1 with Maryana. I was going to also ask that we focus on the photo upload features, their usability and functionality given our more recent sprints have been focused on these features. I'll work with Maryana to create goals, guidance and ways to measure our success as well as ways to solicit feedback for improving the experience in the feature.
On Tue, Dec 18, 2012 at 1:11 PM, Maryana Pinchuk <mpinchuk@wikimedia.org mailto:mpinchuk@wikimedia.org> wrote:
On Tue, Dec 18, 2012 at 11:31 AM, Quim Gil <qgil@wikimedia.org <mailto:qgil@wikimedia.org>> wrote: On 12/14/2012 02:17 PM, Chris McMahon wrote: 2. Decide a mobile area to focus, a way to run the sprint and a date for it. Define also the goals and how to measure the success of the sprint. I'm on board too, but I would like to suggest that Michelle spearhead this activity. She seems to be busy... I can put time organizing the event and promoting it but there is a key aspect YOU (defaulting to Michelle / Maryana?) need to decide: - What problem do we want to solve with this activity? I have some suggestions :) I'd like for us to leverage our editing community to test out contributory features, so we can figure out where in the browser/device matrix our new experimental features (like editing, image uploads, and watchlists) break down, and whether they do so gracefully or not. In the early part of 2013, the mobile team is going to be especially focused on image uploads to meet our goal of 1,000 unique uploaders per month on mobile, so it makes sense to focus the most attention there. In order to have a productive sprint, I'm guessing we'd need to host this session sometime in late January/February, to give the dev team time to iron out the obvious bugs and move contributory features from alpha/beta to production. So that gives us some time to mull over the framework, decide if we want to go the synchronous/asynchronous route, do outreach, etc. :) Why don't we revisit this discussion in early January, after our next big release of features, when we'll have a bit more clarity on the product side? M Once this is clear then we can answer better how, wen and who exactly must be there doing what. ..."a way to run the sprint" is the tricky part. I think there are basically two options: synchronous and asynchronous. Synchronous is arguably more difficult, so lets' talk about that option first... Synchronous test event: we did this successfully for AFTv5. Here is the test plan that I used: http://www.mediawiki.org/wiki/__QA/Article_Feedback_Test_Plan <http://www.mediawiki.org/wiki/QA/Article_Feedback_Test_Plan> . That test plan is based on ideas from "Session Based Test Management", http://en.wikipedia.org/wiki/__Session-based_testing <http://en.wikipedia.org/wiki/Session-based_testing> (Just btw, the software testing articles on enwiki are pretty awful, someday I'd like to clean them all up, but it's a big job) I borrowed a lot of details for synchronous test events from the Weekend Testing Americas group. They found some time ago that Saturdays from 10AM-1PM Pacific time is generally more successful than other times. We had a dedicated test environment and an irc channel. Everyone worked at the same time and collaborated on IRC simultaneously, and it was more fun than you might imagine. Asynchronous test event: For a period of time (a day? a week?) I'm not sure...) everyone participating is testing on their own, pending whatever collaboration they can create among themselves I guess. I think a test plan with "charters" would be required for an async test event, as well as a coordinator to field information, feedback, questions, etc. from participants. I think Yuvi has done this before for mobile, but I don't know any details. Again, without deciding the problem we want to solve it is difficult to find the perfect answer to this. In general I think an approach like this could work: * We have one big goal and then other little goals related. * Each goal has some tasks defined. * Some of the tasks can be started and eventually completed by anybody anywhere. We open the gates for those asap, identifying who can help volunteers here and on IRC. * As the sprint day approaches we can see what hard nuts haven't been solved yet, what tasks benefit from synchronous collaboration. * The goals of the sprint day (end eventually the agenda, if any is needed) will be come clear as the date approaches. * Then the sprint day is today and we all do our best. * After that some of us still need to have energy and time in the following days to process the useful data in the relevant wiki pages, write the blog post and close the activity properly. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/__User:Qgil <http://www.mediawiki.org/wiki/User:Qgil> -- Maryana Pinchuk Associate Product Manager, Wikimedia Foundation wikimediafoundation.org <http://wikimediafoundation.org>
I'm fine with slotting us in for 2/25. I'm still a bit unclear on how this all works, and what information we need to put together to make sure that this is both a fun and useful experience for all. So sure we can do it ... let me know what are the next steps :)
On Thu, Jan 24, 2013 at 12:10 AM, Quim Gil qgil@wikimedia.org wrote:
A month later... :)
Can we agree on a slot for a mobile testing activity at
https://www.mediawiki.org/**wiki/QA/Weekly_goalshttps://www.mediawiki.org/wiki/QA/Weekly_goals ?
As far as I know we still don't have a candidate confirmed for the week of Feb 11 on browser / automated / regression testing. Otherwise the next features / prospective / manual testing week starts on Feb 25.
We can start with a small goal for the week selected, requiring a preparation bringing little overhead to you. Once the goal is defined then we can help preparing the week and handling it. The point of this QA support is precisely to save you work, not to bring you more.
Please consider. If you do have a topic but for some reason you prefer to have it on a later date please let us know as well, and we will book a slot for it.
Thank you!
On 12/18/2012 11:03 PM, Michelle Grover wrote:
+1 with Maryana. I was going to also ask that we focus on the photo upload features, their usability and functionality given our more recent sprints have been focused on these features. I'll work with Maryana to create goals, guidance and ways to measure our success as well as ways to solicit feedback for improving the experience in the feature.
On Tue, Dec 18, 2012 at 1:11 PM, Maryana Pinchuk <mpinchuk@wikimedia.org mailto:mpinchuk@wikimedia.org**> wrote:
On Tue, Dec 18, 2012 at 11:31 AM, Quim Gil <qgil@wikimedia.org <mailto:qgil@wikimedia.org>> wrote: On 12/14/2012 02:17 PM, Chris McMahon wrote: 2. Decide a mobile area to focus, a way to run the sprint and a date for it. Define also the goals and how to measure the success of the sprint. I'm on board too, but I would like to suggest that Michelle spearhead this activity. She seems to be busy... I can put time organizing the event and promoting it but there is a key aspect YOU (defaulting to Michelle / Maryana?) need to decide: - What problem do we want to solve with this activity? I have some suggestions :) I'd like for us to leverage our editing community to test out contributory features, so we can figure out where in the browser/device matrix our new experimental features (like editing, image uploads, and watchlists) break down, and whether they do so gracefully or not. In the early part of 2013, the mobile team is going to be especially focused on image uploads to meet our goal of 1,000 unique uploaders per month on mobile, so it makes sense to focus the most attention there. In order to have a productive sprint, I'm guessing we'd need to host this session sometime in late January/February, to give the dev team time to iron out the obvious bugs and move contributory features from alpha/beta to production. So that gives us some time to mull over the framework, decide if we want to go the synchronous/asynchronous route, do outreach, etc. :) Why don't we revisit this discussion in early January, after our next big release of features, when we'll have a bit more clarity on the product side? M Once this is clear then we can answer better how, wen and who exactly must be there doing what. ..."a way to run the sprint" is the tricky part. I think there are basically two options: synchronous and asynchronous. Synchronous is arguably more difficult, so lets' talk about that option first... Synchronous test event: we did this successfully for AFTv5. Here is the test plan that I used: http://www.mediawiki.org/wiki/**__QA/Article_Feedback_Test_**Plan http://www.mediawiki.org/wiki/__QA/Article_Feedback_Test_Plan < http://www.mediawiki.org/**wiki/QA/Article_Feedback_Test_**Planhttp://www.mediawiki.org/wiki/QA/Article_Feedback_Test_Plan
. That test plan is based on ideas from "Session Based Test Management", http://en.wikipedia.org/wiki/_**_Session-based_testing<http://en.wikipedia.org/wiki/__Session-based_testing> <http://en.wikipedia.org/wiki/**Session-based_testing<http://en.wikipedia.org/wiki/Session-based_testing>>(Just btw, the software testing articles on enwiki are pretty awful, someday I'd like to clean them all up, but it's a big job)
I borrowed a lot of details for synchronous test events from the Weekend Testing Americas group. They found some time ago that Saturdays from 10AM-1PM Pacific time is generally more successful than other times. We had a dedicated test environment and an irc channel. Everyone worked at the same time and collaborated on IRC simultaneously, and it was more fun than you might imagine. Asynchronous test event: For a period of time (a day? a week?) I'm not sure...) everyone participating is testing on their own,pending whatever collaboration they can create among themselves I guess. I think a test plan with "charters" would be required for an async test event, as well as a coordinator to field information, feedback, questions, etc. from participants. I think Yuvi has done this before for mobile, but I don't know any details.
Again, without deciding the problem we want to solve it is difficult to find the perfect answer to this. In general I think an approach like this could work: * We have one big goal and then other little goals related. * Each goal has some tasks defined. * Some of the tasks can be started and eventually completed by anybody anywhere. We open the gates for those asap, identifying who can help volunteers here and on IRC. * As the sprint day approaches we can see what hard nuts haven't been solved yet, what tasks benefit from synchronouscollaboration.
* The goals of the sprint day (end eventually the agenda, if any is needed) will be come clear as the date approaches. * Then the sprint day is today and we all do our best. * After that some of us still need to have energy and time in the following days to process the useful data in the relevant wiki pages, write the blog post and close the activity properly. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/**__User:Qgil<http://www.mediawiki.org/wiki/__User:Qgil> <http://www.mediawiki.org/**wiki/User:Qgil<http://www.mediawiki.org/wiki/User:Qgil>-- Maryana Pinchuk Associate Product Manager, Wikimedia Foundation wikimediafoundation.org <http://wikimediafoundation.**org<http://wikimediafoundation.org>-- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/**User:Qgilhttp://www.mediawiki.org/wiki/User:Qgil
On 01/24/2013 12:06 AM, Michelle Grover wrote:
I'm fine with slotting us in for 2/25.
Great! Slot booked at
https://www.mediawiki.org/wiki/QA/Weekly_goals
I'm still a bit unclear on how this all works, and what information we need to put together to make sure that this is both a fun and useful experience for all. So sure we can do it ... let me know what are the next steps :)
This is new to everybody and we are ironing details as we go. For instance, I just added a section "Requesting a slot" to the page above.
The week of Feb 25 is about manual testing. The first thing is to define a goal. Weeks ago you mentioned Image Uploader as a candidate for testing. Is that still the case? Otherwise let's find the right feature.
I'd rather go for smaller & well defined goals rather than broader and more ambitious. Especially for these first iterations where we are the first ones learning and when so much specific effort needs to be put in every week. After a first mobile week it will be easier to plan accordingly for a next mobile week.
On Jan 24, 2013, at 9:52 AM, Quim Gil qgil@wikimedia.org wrote:
On 01/24/2013 12:06 AM, Michelle Grover wrote:
I'm fine with slotting us in for 2/25.
Great! Slot booked at
https://www.mediawiki.org/wiki/QA/Weekly_goals
I'm still a bit unclear on how this all works, and what information we need to put together to make sure that this is both a fun and useful experience for all. So sure we can do it ... let me know what are the next steps :)
This is new to everybody and we are ironing details as we go. For instance, I just added a section "Requesting a slot" to the page above.
The week of Feb 25 is about manual testing. The first thing is to define a goal. Weeks ago you mentioned Image Uploader as a candidate for testing. Is that still the case? Otherwise let's find the right feature.
I'd rather go for smaller & well defined goals rather than broader and more ambitious. Especially for these first iterations where we are the first ones learning and when so much specific effort needs to be put in every week. After a first mobile week it will be easier to plan accordingly for a next mobile week.
By Feb 25 we should have two image upload workflows on the mobile web: uploading and inserting images directly into an article, and uploading from the side navigation panel and donating the image to Commons. The latter will be much easier to test, since the former requires finding an article with no images, then adding an image that's appropriate for the article in question. The latter can be any image, really, as long as it's not copyrighted. Both of these will require users to be logged in.
I'd suggest that as a first pass we simply invite users to kick the tires with a variety of devices/browsers on the upload-from-sidebar -- only top shelf brands are going to offer full upload functionality, but it would be good to make sure that older devices/quirky browsers decay gracefully and don't introduce any unexpected chaos.
Does that sound reasonable? I'm new to this, too, but very interested in seeing how it goes! :)
I had a chat with Yuvi today and have some ideas for small test cases that would be meaningful for both Photo upload and commons. I picked the 25th so we would be far enough in the sprint to have something viable to test.
On Thu, Jan 24, 2013 at 8:16 PM, Maryana Pinchuk mpinchuk@wikimedia.orgwrote:
On Jan 24, 2013, at 9:52 AM, Quim Gil qgil@wikimedia.org wrote:
On 01/24/2013 12:06 AM, Michelle Grover wrote:
I'm fine with slotting us in for 2/25.
Great! Slot booked at
https://www.mediawiki.org/wiki/QA/Weekly_goals
I'm still a bit unclear on how this all works, and what information we need to put together to make sure that this is both a fun and useful experience for all. So sure we can do it ... let me know what are the next steps :)
This is new to everybody and we are ironing details as we go. For
instance, I just added a section "Requesting a slot" to the page above.
The week of Feb 25 is about manual testing. The first thing is to define
a goal. Weeks ago you mentioned Image Uploader as a candidate for testing. Is that still the case? Otherwise let's find the right feature.
I'd rather go for smaller & well defined goals rather than broader and
more ambitious. Especially for these first iterations where we are the first ones learning and when so much specific effort needs to be put in every week. After a first mobile week it will be easier to plan accordingly for a next mobile week.
By Feb 25 we should have two image upload workflows on the mobile web: uploading and inserting images directly into an article, and uploading from the side navigation panel and donating the image to Commons. The latter will be much easier to test, since the former requires finding an article with no images, then adding an image that's appropriate for the article in question. The latter can be any image, really, as long as it's not copyrighted. Both of these will require users to be logged in.
I'd suggest that as a first pass we simply invite users to kick the tires with a variety of devices/browsers on the upload-from-sidebar -- only top shelf brands are going to offer full upload functionality, but it would be good to make sure that older devices/quirky browsers decay gracefully and don't introduce any unexpected chaos.
Does that sound reasonable? I'm new to this, too, but very interested in seeing how it goes! :)
On 01/24/2013 07:30 PM, Michelle Grover wrote:
I had a chat with Yuvi today and have some ideas for small test cases that would be meaningful for both Photo upload and commons. I picked the 25th so we would be far enough in the sprint to have something viable to test.
Is there a page under https://www.mediawiki.org/wiki/Mobile_QA or elsewhere where we could start drafting all this? No need to create a new page if we can start from an existing one, and make it ready to welcome DIY testers.
As an example, look at https://www.mediawiki.org/wiki/VisualEditor/Testing_Non-Latin_Characters_Inp... - a page that only a week ago started as a rough draft.