Jump to content

Extension:Newsletter/Proposal

From mediawiki.org

Newsletter Mediawiki Extension

[edit]
Public Url
https://www.mediawiki.org/wiki/User:Tinaj1234/Proposal
Phabricator report
https://phabricator.wikimedia.org/T76199
Announcement
https://meta.wikimedia.org/wiki/Grants:IdeaLab/Newsletter_extension_for_MediaWiki

Name and contact information

[edit]
Name
Tina Johnson
Email
tinajohnson.1234@gmail.com
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
Talk Page: User: Tinaj1234

Project summary

[edit]

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:

Readers

  • 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.

Publishers

  • 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.
Possible mentors

Implementation

[edit]

What is expected:

Front end

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

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.

Back end

  • 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

[edit]
  • 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 - 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?

Microtasks

[edit]

Project schedule

[edit]
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/14 - 10/05/14
Front end Phase I - Publisher's view, Newsletter skeleton 20/05/14 - 30/05/14
Adding Newsletter tab to Special:Preferences 31/05/14 - 15/06/14
Code review, Fixing bugs 16/06/14 - 24/06/14
Mid Term Evaluation 24/06/14 - 28/06/14
Front end Phase II - Reader's view 29/06/14 - 17/07/14
Integrating features of Massmessage and Echo 28/07/14 - 15/07/14
Writing unit tests, Testing the work flow 15/07/14 - 30/07/14
Writing Documentation, Deployment 30/07/14 - 16/08/14
Final Report Submission 17/08/2014

About you

[edit]

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.

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

[edit]

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

[edit]