Hi list,
I recently helped shepherd a new skin into Mediawiki;
https://www.mediawiki.org/wiki/Skin:Erudite
I would like to think it is perfect in every way, but one area it
hasn't had any love is making sure it works well on mobile devices.
To the best of my knowledge it shouldn't do anything particularly
heinous, but I don't have any such devices to test it on. If anybody
has a few minutes and could have a play, and see if anything could
be improved, please do and let me know on list.
A live example of it is at
https://www.dur.ac.uk/nick.white/erudite-demo/mediawiki-current/
which should have full editing etc rights enabled. It's a dummy
wiki, so add whatever you like.
Thanks in advance!
Nick White
<brion> and <tfinc> told me that the "Wikimedia Mobile" product in
Wikimedia Bugzilla is rather dead and that bugs should be reported
either against "Wikipedia App"/"Wiktionary App"/"WikiLoves Monuments
Mobile" for apps, or "MediaWiki extensions" -> "MobileFrontend" for the
mobile website.
Is this general consensus? (Silence means agreement.)
If so:
1) There are 56 open tickets that need retriaging
(your help is welcome):
https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&resolution…
2) I am going to close "Wikimedia Mobile" product for new bug
entries, and edit its product description to state where to
file tickets instead.
Thanks for your input!
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
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.
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
This is a heads up that the Wikimedia Mobile team is going to be un-
publishing the WLM app from the Google Play store.
Practically this means that you will no longer be able download the WLM app
from the market. You *will* still be able to download all previous releases
from :
http://www.mediawiki.org/wiki/Mobile/Release_history#Apps
This change will not affect any of our current users.
Why are we doing this? The app was specifically crafted and resourced with
an expiration date of the WLM contest. Now that WLM has fully wrapped up
we'd like to take what we've learned and apply all of our energy to meeting
our annual goal of 1,000 photo uploads / month. In order to do this we need
to take what we've learned from the WLM app and channel it into a more
generic mobile web and app experience. This requires us to free up
resources that would be supporting the app for bug fixes, legal updates,
etc.
What does this mean to the existing users? Nothing much. The mobile team
put in a redirect so that the app works with the tool server now. That will
make it so that no existing users are interrupted for the life time of the
TS.
As the mobile team executes on the next six months were keenly interested
in building solutions that can easily work for WLM in the future.
Stay update with what were working on by following the engineering report:
http://www.mediawiki.org/wiki/Wikimedia_engineering_report/2012/October#Mob…
--tomasz
Hi there,
SUMMARY
Does it make sense to organize a sprint for mobile users and developers
to identify and process mobile use examples to feed our QA & automated
regression tests?
If so, I can help connecting the dots and getting things done.
EXTENDED PLAY
There have been different conversations that could (theoretically)
converge in a single line of events:
- One of the goals of the Wikimedia Foundation Engineering team is to
organize a "First substantive systematic outreach to potential testers"
https://www.mediawiki.org/wiki/Wikimedia_Engineering/2012-13_Goals#Mileston…
- Testing / QA pilot with the Mobile team, an idea briefly discussed
with Michelle Grover and Tomasz Finc that I'm happy to help making it
happen.
- Polishing some pages written mainly by Chris McMahon and Željko
Filipin, connecting them with an actual short term plan:
* http://www.mediawiki.org/wiki/QA/Strategy#Test_automation
*
http://www.mediawiki.org/wiki/Browser_testing/community_automated_browser_t…
* http://www.mediawiki.org/wiki/QA/test_backlog
- Creating a MediaWiki Group to help the people interested in browser QA
stick together and reach to new contributors and similar communities out
there: http://www.mediawiki.org/wiki/Groups
Because I'm lazy ;) I'd rather connect all these activities in one stream:
1. Have a first go through the documentation until it can be digested by
mobile users and QA experts willing to help.
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.
3. Create a MediaWiki group at least with Chris, Michelle and the next
three people joining. Start listing the right resources. Let newcomers
sign up.
4. Advertise the sprint and the group.
5. Keep polishing the docs as the sprint approaches and people shows up
with new questions.
6. Run the sprint. Have fun. Meet the goals.
7. Process the data generated. Distribute barnstars to contributors.
Publish a blog post summarizing the whole thing.
8. Another round of polishing and completion to the docs based on the
experience accumulated. Leave everything as ready as possible to
organize the next activity without needing e.g. someone like me.
How does this sound?
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
(x-posted on WM-l and Wikitech-l – pardon the spam!)
Hi all,
This Thursday at 18:00 UTC (10 a.m. PST) the mobile development, design,
and product team will be hosting IRC office hours. In addition to general
introductions and Q&A, we'd like to spend some time talking about our
current work – bringing contributory features like editing and image
uploads to mobile devices. Please see
https://meta.wikimedia.org/wiki/IRC_office_hours#Upcoming_office_hoursfor more
details.
Thanks, and hope to see you in #wikimedia-office on Thursday!
--
Maryana Pinchuk
Associate Product Manager, Wikimedia Foundation
wikimediafoundation.org
Howdy people, I'm not ignoring you but I'm trying to play catchup with
email and finish coordinating some testing for the iOS app. I'll respond
in detail to this tonight or this weekend.
Thanks!
Michelle
On Fri, Dec 14, 2012 at 3:17 PM, Chris McMahon <cmcmahon(a)wikimedia.org>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.
>
> ..."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.
>
> Brain dump complete, comments welcome.
> -Chris
>