Extension:Newsletter/Proposal

Newsletter Mediawiki Extension

 * Public Url: https://www.mediawiki.org/wiki/User:Tinaj1234/Proposal
 * Bugzilla report: https://bugzilla.wikimedia.org/show_bug.cgi?id=62601
 * Announcement: http://lists.wikimedia.org/pipermail/wikitech-l/2014-March/075265.html

Name and contact information

 * Name:Tina Johnson
 * Email:tinajohnson.1234@gmail.com
 * Timezone: Kolkata, UTC+5:30
 * Typical working hours: 5pm to 2am or 9am to 9pm
 * IRC Nick: tinaj1234 on Freenode ( Channels: #mediawiki, #wikimedia-dev, #wikimedia-tech )
 * Other contact details: Talk Page: User: Tinaj1234

Project summary
Wikimedia projects and developers could use an extra hand when it comes to communicating the recent activities to the community as well as to the outside. The best possible solution we have at hand is a Newsletter, which brings together all the relevant news/updates at one place.

Current Scenario

As of now, if a user has to send a mass message he has to create a page list with the above said format. That is, for each recipient wikitext has to be added in the page list (see image below). This is not at all user friendly.

What the project would accomplish

If we were to use a more lightweight format like JSON (JavaScript Object Notation) for serialization, both frontend and backend can be revolutionized. Using JSON, we could store the information in a more structured way. The JSON structure will look like:

A ContentHandler for the same will have to be provided, one which extends from ContentHandler class and TextContentHandler class. With this, each page is assigned a content format. This project would implement:
 * A user friendly interface - An 'Add page' button which would open up a JS dialogue box where the user adds the individual pages to which he wants to send the message and then saves it using ajax.The user can add three kinds of pagesː
 * A page list which has wikitext content - Here we make use of #target and all other related functions
 * A page list which has JSON content - JSON ContentHandler is used
 * A page which is not a list - If a number of individual pages which has neither of the above formats are added by user, a JSON page list will be created. But if just one page is added by user, a dilemma arises whether a list should be created or not. This is when the question "So I add a single page now, but what if tomorrow I have the idea that I need to add another page?" comes into context. On discussions with my mentor, we both agreed that creating a JSON list right away would be better. Again, what if the user want to add or remove a page to an already existing list? We plan to implement this functionality as well.


 * In order to have backward compatibility, we will use a function to identify if the page content format is wikitext or JSON. If the format is JSON, then its ContentHandler will be used. Or else if the content is wikitext, #target comes into play.


 * Possible mentors
 * Kunal Mehta, Reedy

Deliverables
What is expected:

The MassMessage UI will be completely altered for the better. An 'Add page' button would be implemented which would open up a JS dialgue box. User can add pages to be added and when 'Add' button is clicked, a html page is displayed with the list of all pages added by user. From this list, the user can delete any page if required. When 'Send message' button is clicked the message will be sent to the pages in the list and will be followed by a JS dialogue box. Here the user will be provided the following options: I'm assuming that the last said would be the most challenging part of the project as there are can be a number of test cases. Few test cases are: * Microtasks
 * 1) Save as new list
 * 2) Update an existing list(s)
 * 3) Keep the existing list(s) intact
 * 1) An individual page added - A JSON page created at the backend and at the frontend the user is prompted for a name for the list (see image).
 * 2) Wikitext page lists alone - We stick with the #target parser function.
 * 3) JSON page lists alone - User has the option to either merge the lists or just keep them separate.
 * 4) JSON page list(s) + individual page(s) - When all the target pages are listed, user may trash out any recipient as per his requirement. After this he can either create a new list or merge the new list with other existing lists.
 * 5) Wikitext page list(s) and individual page(s) - Discussions are still pending. The best option will be creating a new JSON page but then again backward compatibility is to be considered.

About you
I'm a 20 year old second year Computer Science Engineering undergraduate at Amrita Vishwa Vidyapeetham, Kollam. I'm a proud member of FOSS club in my college, which explains my interest in Open Source contributions. Also, this club is why and how I started contributing to Mediawiki. To get done with my first bug wasn't easy. Struggled to understand the code, even the instructions from IRC. But eventually when the patch was merged and when I got to see the trivial change that I made, it was pure joy. And that's what I love about contributing to Open Source. I get to make a difference, or even better voice my opinion on how something should be done.

When the project is finished, not just page input list will be improved but many more will be accomplished. As you go deeper into the idea being implemented, you can see how the extension itself is upgraded to a better version. Mediawiki is how I got started with bug fixing. The community has always been so kind with instant replies on IRC's and their keen interest in solving issues however trivial they may be. So when I thought of doing a GSoC project with Mediawiki, it just felt right.

Participation
Being part of the FOSS Club enables me to be connected with the Open Source Community around after my college hours. I try to blog regularly on new knowledge learnt. My blog will be the regular source of all progress during the coding phase. I actively respond to emails and am active at the wikimedia IRC channels, where I actively communicate with the community. All the source code written will be pushed to github repositories MassMessage. Test results will be put up on subpages of MassMessage or even a thread can be started so that developers can share their ideas and views.

Past open source experience

 * Bug fixes in Mediawiki.
 * Github profile:Tina Johnson
 * Gerrit Changes:Tinaj1234
 * Daily Wallet - Co-authored this webapp