Extension:Newsletter/Proposal
This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. This was a Google Summer of Code/2015 proposal. See phab:T93583 and phab:T76199. |
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
- 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]- https://phabricator.wikimedia.org/T72784
- https://phabricator.wikimedia.org/T92728
- https://phabricator.wikimedia.org/T57367
- https://phabricator.wikimedia.org/T62725
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]- Bug fixes in Mediawiki.
- Github profile:Tina Johnson
- Gerrit Changes:Tinaj1234
- Daily Wallet - Co-authored this webapp