Jump to content

Automatic cross-language screenshots

From mediawiki.org

Automatic cross-language screenshots for user documentation

[edit]

Public URL: https://www.mediawiki.org/wiki/User:Vikassy/GSoC14

Bugzilla report: https://bugzilla.wikimedia.org/show_bug.cgi?id=62737

Announcement: http://lists.wikimedia.org/pipermail/wikitech-l/2014-March/075321.html , In QA mailing list: http://lists.wikimedia.org/pipermail/qa/2014-March/001285.html

Name and contact information

[edit]

Name: Vikas S Yaligar

Email: vikasyaligar.it@gmail.com

IRC: vikas/vikassy on freenode

Blog: vikassy.github.io

Github: www.github.com/vikassy

Location: Surathkal [During GSOC: Bangalore], India (UTC+05:30)

Typical working hours: 12:30 pm - 09:30 pm (UTC) (adjustable)

Synopsis

[edit]

Problem

MediaWiki is a large and complex piece of software, and the user guide for core and those for extensions (like VisualEditor or Translate) each have a large number of images illustrating functions and stages of operation. However, these often date quickly as the software changes, and are generally only available in English or at best a few languages, which means that non-English users are not as well served.

QA Mailing list discussion

In February 2014, there was a discussion(1,2) on this as screenshot hack in QA mailing list.

How is it currently being solved?

Currently all the screenshots are taken manually and uploaded after cropping. But Wikimedia supports 287 languages, hence doing it manually is redundant and time consuming.

Solution

A web automation which will capture the current look of the software with screenshots of the entire browser window, or sections of it, doing some scripted actions, across the hundreds of languages that MediaWiki supports and upload it to Wikimedia commons. Hence whenever a functionality is changed, the automation can be rerun to get updated images.

Implementation

Currently there are many features of extensions are being tested using browser testing. It would be sensible to use them as a part of current project for taking screenshot. It is feasible to use the mediawiki_selenium gem to achieve the automation for screenshots. More information about this can be found in deliverables.

Possible mentors

Amire E Aharoni , James Forrester  and the Quality Assurance team 

Deliverables

[edit]
From-To Date Work
April 22 to April 27 GSOC community bonding period
April 28 to May 6 College examination
May 7 to May 16 Update mediawiki_selenium gem to take screenshots if test passes
May 17 to May 24 Addition of tag and writing new browser test(if necessary) for VisualEditor
May 25 to June 5 Updation of hook to crop the screenshot
June 5 to June 12 Updation of hook to upload the image
June 12 to June 22 Creation of jenkins job and run them
June 23 to June 26 Making report for mid evaluations
June 27 Mid term evaluation
June 28 to June 30 Confirmation of required images, make any changes required
July 1 to July 10 Same configuration(like Visual editor) for other extensions
July 10 to July 20 Increasing the performance
July 20 to July 25 Confirm all uploading of all images and make any changes required
July 26 to August 10 i18n testing [Bonus]
August 11 Pencils Down
August 22 Submitting of code samples to Google
August 22 - .... Continue contributing

What exactly work is done at each step is explained below:

GSOC community bonding period

Aim: Understanding of how Quality Assurance team works.

Tasks:

  • Meeting new people in team and know what they are working on.
  • Understand how jenkins job are created and run on cloudbees.
  • Understand how saucy labs are being used.
  • Confirmation of requirements, by knowing exact scenarios to which screenshot should be taken.

Duration: 5 days

College examination

Aim: Be in contact with community. Get done with college examinations

Duration: 10 days

Update mediawiki_selenium gem to take screenshots if test passes

Aim: Updating mediawiki_selenium to take screenshot on test pass.

Tasks:

  • In after scenario hook, change the code to take screenshot when test passes.
  • Add new environment variables to check if screenshot is taken when tests are passed and path to which it should be added.
  • Updating README.

Bonus: Making this work on saucy labs, Bug #46890

Duration: 10 days, because bonus problem might be hard.

Addition of tag and writing new browser test(if necessary) for VisualEditor

Aim: Classification of current browser tests and adding them @documentation-screenshot to it. If a scenario is not covered, then create a new one.

Tasks:

  • Classification and adding tags, so that a new jenkins job can be run with only those scenario running.
  • Writing new browser tests for other scenarios not covered.

Bonus: Structuring the current features.

Duration: 8 days, because writing new scenarios and testing them might take time.

Updating after scenario hook to crop the screenshot

Aim: When tests are passed, a after hook will be made for @documetation-screenshot, which will crop a part of the image.

Tasks:

  • Implementing this solution. [I have tried it once using Watir::Browser and it works].
  • Check with all browsers, tends to give good screenshot and is faster.
  • Test if output of running the test is giving exact image.

Duration: 12 days, because this is the first time I am doing it for current browser tests.

Updating after scenario hook to upload the image

Aim: Uploading the cropped images to Wikimedia commons

Tasks:

  • Update the after hook made for @documentation-screenshot
  • Upload the image using API:Upload

Duration: 7 days, because this is first time uploading of image is being done.

Creation of jenkins job and running them

Aim: Generate jenkins job using jenkins job builder (jjb)

Tasks:

  • Learn how to use the job builder.
  • Create it for all language.
  • Put it in cloudbees.

Duration: 10 days, as I have to learn jjb.

Same configuration(like Visual editor) for other extensions

Aim: When it is working for VisualEditor, then start working on same thing for other extensions.

Tasks:

  • Classification and adding tags, so that a new jenkins job can be run with only those scenario running.
  • Writing new browser tests for other scenarios not covered.
  • Creation of new jobs and making them run on cloudbees.

Duration: 10 days, as I have to check each extension.

Increasing the performance

Aim: Check all ways in which one can improve the performance.

Tasks:

  • Try implementing parallel_test and check the performance.
  • Search for better solution, if found any implement it.

Bonus: Bug #55867

Duration: 10 days

i18n testing

Aim:  i18n testing using browser tests

Tasks:

  • Select some of the problems which can be tested from here .
  • Write new tests.

Duration: 16 days, because whole concept is very new for me.

Participation

[edit]

My process of participation in project will be as follows:

  • Notify mentors and Quality Assurance team(through mailing list) about the work for the week.
  • If stuck at any point, search for solutions first.
  • If searching did not help, check if mentors/QA team members are free at that point of time in IRC, if so ask them about the problem.
  • If no one is free, then put it up in mailing list and wait for some time for response.
  • If the problem is complex, ask other people working outside community for help.

About me

[edit]
Education completed or in progress

I am studying 3rd year(Bachelors of Technology) in National Institue of Technology Karnataka Surathkal.

How did you hear about this program?

From friend who had been selected for GSOC.

Will you have any other time commitments, such as school work, another job, planned vacation, etc., during the duration of the program?

No, only final exam from April 28 to May 6.

We advise all candidates eligible to Google Summer of Code and FOSS Outreach Program for Women to apply for both programs. Are you planning to apply to both programs and, if so, with what organization(s)?

Only GSOC.

Past experience

[edit]
Please describe your experience with any other FOSS projects as a user and as a contributor

I started my journey by learning git and adding all of my projects to opensource. Then I started to look for bugs which I can solve. I made my first contribution by fixing a small bug in active_admin gem, which made me understand how one can automatically generates documentation for code written and experienced support for contribution. Hence I decided I should be a part of organization which supports FOSS projects.

Please describe any relevant projects that you have worked on previously and what knowledge you gained from working on them (include links)

In Wikimedia I enjoyed worked on Bug #62152 , Bug #58900 and happily working on Bug #55867, with these I learnt how to write browser tests and how these are run in cloudbees. I have contributed to Codeniti, by being a part of Map my village project(contribution), with this I learnt to create and collaborate with a team to create applications. I have also worked on rails internals and tor projects, which gave made me realize how important tests are.

What project(s) are you interested in (these can be in the same or different organizations)?

This one, because I find it interesting.

Any other information

[edit]

A basic microtask has been made on the current project, which takes the picture of Heading pull down menus of the Visual editor. You find the instructions and code in my github repository.

See also

[edit]