Newsletter Mediawiki Extension
Public Url: https://www.mediawiki.org/wiki/User:Tinaj1234/Proposal
Phabricator report: T76199
Name and contact information
Name: Tina Johnson
Timezone: Kolkata, UTC+5:30
Typical working hours: 5pm to 2am (weekdays), 9am to 9pm (weekends)
IRC Nick: tinajohnson on Freenode ( Channels: #mediawiki, #wikimedia-dev, #wikimedia-tech )
Other contact details: Tinaj1234
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. This is where the idea of a newsletter extension comes in, allowing any number of wikis or projects to install the feature and deliver the latest updates to users(readers) through a 15 second subscription. The extension would have two genre of users:
- A reader can subscribe to any number of newsletters easily through the Newsletter tab in Special:Preferences.
- Newsletters the reader has subscribed to show up in Special:Newsletter. The idea is to portray all the subscribed newsletters as tiles, hovering on which old issues of the corresponding newsletter pops out in a stacked manner ( yet to be decided ).
- A user can choose how he/she should be notified of updates, possibly a message on User_talk page or just a notification - here we can make use of the functionality of Echo or MassMessage or otherwise an email. This choice can be at the time of subscribing.
- Unsubscribing a newsletter would be just a click away.
- After the extension is installed in a wiki, the publisher has many privileges including creating, editing, discarding a newsletter. There can be many contributors to a newsletter just the way a wiki page has many contributors.
- Notifications are send out to subscribers when a newsletter is ready to be published.
What is expected:
A typical newsletter would have:
- A set of interconnected wiki pages - Starts off with a introductory home page with information regarding the newsletter like an overview of the contents.
- Latest issue - A page where the latest newsletter shows up.
- Archive of older issues - User can navigate to this page to access older issues
Special:Newsletter page of a user :
An early prototype of Special:Newsletter for a user would list the available newsletters in his/her wiki along with a listing of published issues (not all but the latest ones) beneath corresponding newsletter. Later through the project, this can possibly take a tile structure, with the issues stacked behind the newsletter logo/thumbnail. A user should also have the option to subscribe to the same after viewing, which would add an entry in the database. The functionality 'View/Manage subscriptions' is planned to have integrated with Special:Preferences ( just another tab ), but a copy of that should be made available in Special:Newsletter too, so that a user can manage subscription without shifting from the page.
Special:Newsletter page of a Admin/Publisher
Special:Newsletter will other subsections, including 'Create a Newsletter' and 'My Newsletters'. An admin should be able to see the current list of subscribers to his newsletter ( simple COUNT(*) will do ). A unfinished newsletter can be saved as a draft and on acquiring special permissions, other publishers can collaborate in editing the newsletter. A 'Stop publishing' option in the newsletter options menu would be nice, so that a bool flag in the database is set/unset corresponding to the publishing status.
This extension is very much similar to MassMessage extension, mass messaging a newsletter. Also, Echo can be extensively used for sending out notifications whenever a new issue is published. We could make use of Flow and provide the user with an option to receive his notifications as message on his talk page.
- newsletter_description table to store general information of a newsletter, which can be the creator, time stamp of creation, newsletter_id and a newsletter_ispublished flag which can control the visibility of a newsletter
- newsletter_text table to store the content of the newsletter, which would enable global access to the newsletter for all users, with newsletters being referenced from newsletter_description
- newsletter_subscription table should contain mappings of users subscribed to newsletters, referencing from newsletters_description. When a user clicks on 'subscribe', an entry should be done in this table with relevant details. Further, running a simple SELECT query on this table should give all the newsletters the user is subscribed to - and can be used to fill up Special:NewsLetter for that user.
Questions To Be Addressed
- Should a new user be allowed to subscribe to a newsletter without creating a new account ? Can a newsletter be subscribed just with a email id ?
- Can authors set a draft to auto-publish at a specific time?
- Already addressed - T59935 (Handling subscriptions to newsletter through user preferences)
- What would the interface for authors and administrators be like? A tile view, showing up a stack of tiles of old issues on hovering over a tile is one of the suggestions (to be discussed later in the project)
- How do authors publish a draft? How do admins define who can publish?
- Can authors set a draft to auto-publish at a specific time?
|Tasks to be completed||Timeline|
|Setting up environment, prepare a basic skeleton of the extension||28/03/15 - 20/04/15|
|Set up the database for the newsletter extension||21/04/15 - 10/05/15|
|Front end Phase I - Publisher's view, Newsletter skeleton||20/05/15 - 30/05/15|
|Adding Newsletter tab to Special:Preferences||31/05/15 - 15/06/15|
|Code review, Fixing bugs||16/06/15 - 24/06/15|
|Mid Term Evaluation||24/06/15 - 28/06/15|
|Front end Phase II - Reader's view||29/06/15 - 17/07/15|
|Integrating features of MassMessage and Echo||28/07/15 - 15/07/15|
|Writing unit tests, Testing the work flow||15/07/15 - 30/07/15|
|Writing Documentation, Deployment||30/07/15 - 16/08/15|
|Final Report Submission||17/08/2015|
I'm a 21 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.
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.
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 of Newsletter. Test results will be put up on mailing lists so that developers can share their ideas and views and recommend alterations.
Past open source experience
- Bug fixes in Linux Kernel