Change Details

NOTE: This Google Summer of Code project has been completed successfully. Thank you @tinaj1234 for your contributions, and thank you @01tonythomas for your technical mentoring. This team has worked very well so far! For details, read {T109288}. The work continues at {T110170}. As always, your feedback and contributions are welcome. This is not an internship project anymore; patches are very welcome. :) == Newsletter extension == An extension allowing publishers to create newsletters and announce new issues, and allowing users to browse and subscribe to newsletters. A #Google-Summer-of-Code-2015 project lead by @tinaj1234, mentored by @01tonythomas and @qgil. Currently working on {T99784} and blockers. Weekly reports: T100997 Weekly meetings: every [[ http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150605T1030 | Thursday at 10:30 UTC ]] (4pm IST, 12:30 CEST, 3:30 PST) in `#wikimedia-ect` IRC. URL of web proxy of Labs instance where development takes place : http://newsletter-test.wmflabs.org/ == Plan == === Readers === * **A catalog of newsletters in one multilingual wiki** (Meta). Let's start defining a single translatable location to find all the newsletters. Meta is the logical choice. No matter which project the newsletter authors come from, all of them would create and organize their newsletters in a common location. * Easy subscription. As a logged-in user, click a button. As anonymous user, log in or create an account. (Ideally just entering an email address would work too, with confirmation). Question: should an email address in your profile be required? Can this be checked? Echo probably has solved this. * A notification is received when a new issue is published. Notifications are handled via Echo, and therefore they can be received via web or email according to user preferences. * Easy to unsubscribe. As a logged-in user, click a button. Accessing a URL from notifications should unsubscribe you as well, after confirmation. * Usernames and emails of subscribes should be kept private. The number of users subscribed to a newsletter would be public (and eventually used to promote popular newsletters). === Publishers === * A process defining the conditions in which a newsletter can be created, featured, demoted, closed (actions that might imply database changes). Just a basic framework to promote best practices and prevent abuse. * Once a newsletter is created, maintaining the content (homepage, subpages) could be done in a plain wiki way for creating pages, watching, editing, reverting, protecting if needed... New content is in practice a draft, since it hasn't been announced to the subscribers. Whoever wants to watch changes can read the drafts and get involved. * Once a new issue (a page) is ready, the owners of the newsletter send a notification. This requires special permissions. **Permissions** Any autoconfirmed user can become a publisher - create newsletters, announce issues, manage newsletters because of two particular reasons ( quoting Quim ): # Autoconfirmed users can create newsletter pages and issues anyway (even anonymous can). # Even if a publisher were to cause any kind of damage it will affect popularity of their newsletters as well. The extension takes care of subscriptions to the newsletter and notifications from newsletters and hence the creation of newsletters and issues are external to our extension. === Newsletters === A newsletter generally has one or more of the following properties (some newsletters have more of these than others): * Home page: a page that contains information about the newsletter and what it contains * Current issue page: self-explanatory * Archive pages: past editions of the newsletter that were previously published * Authors / Editors: a group of people that are allowed and/or expected to contribute content * Publishers: a group of people that are allowed to finalize an edition and publish it to readers Most likely, showing a user (on the preferences page mentioned above) a link to the home page, a description of the newsletter, and maybe a link to the current issue and archive pages would be useful. As mentioned in a comment below, it would probably be best to shift management of authors and editors to the existing page protection feature, i.e., if the newsletter really needs to be protected from unauthorized editing, make a restriction level and assign authors the necessary permission. Publishers would probably need separate management, and would probably be maintained in the same interface that information about the newsletter itself is maintained. ===Backend=== Check this Etherpad entry on discussions with hoo: https://etherpad.wikimedia.org/p/newsletterExtension While discussing with other developers, we realized there are two options for the extension's backend architecture - either use Contenthandlers or use Database( sql tables ). As of now while we prepare the patches for MVP, the database approach is taken. To choose the best for the extension out of all available options at it's earliest stages of development would be the apt thing to do, hence opening up this section for further discussions. === See also === * https://www.mediawiki.org/wiki/Extension:Newsletter * https://meta.wikimedia.org/wiki/Grants:IdeaLab/Newsletter_extension_for_MediaWiki ===Proposed Schedule=== | **Tasks to be completed **|**Timeline**|**Remarks**| |Create Wikimedia Labs project, create instance, community bonding| 28/03/15 - 30/04/15| Created Labs project 'newsletter' and instance, 'newsletter-test'. Successfully ssh-ed to the instance| |Decide on MVP plan and create necessary tasks|01/05/15 - 05/05/15|Done | |Create the Special:NewsLetterCreate interface, and design DB ( the new table )| 06/05/15 - 10/05/15|Done | |Create the Special:NewsLetterManage interface - Publisher's view, Newsletter skeleton| 20/05/15 - 30/05/15|Done | |Create Special:Newsletters and deploying features on vagrant| 31/05/15 - 15/06/15|Done | |Adding newsletter in Notifications tab of Special:Preferences and completing T101546| 16/06/15 - 24/06/15|Done | | Mid Term Evaluation| 26/06/15 - 03/07/15|Done | | Work on Blockers and complete extension considering case of Meta alone and no inter wiki newsletters| 04/07/15 - 20/07/15|Done | | Work on T102945, T101832, T104829| 21/07/15 - 10/08/15|Done | | Writing unit tests, testing the work flow, documentation, deployment | 11/08/15 - 20/08/15|Continuing | | Final Report Submission| 21/08/2015|Pending |

NOTE: This Google Summer of Code project has been completed successfully. Thank you @tinaj1234 for your contributions, and thank you @01tonythomas for your technical mentoring. This team has worked very well so far! For details, read {T109288}. The work continues at {T110170}. As always, your feedback and contributions are welcome. This is not an internship project anymore; patches are very welcome. :) == Newsletter extension == An extension allowing publishers to create newsletters and announce new issues, and allowing users to browse and subscribe to newsletters. A #Google-Summer-of-Code-2015 project lead by @tinaj1234, mentored by @01tonythomas and @qgil. Currently working on {T99784} and blockers. Weekly reports: T100997 Weekly meetings: every [[ http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150605T1030 | Thursday at 10:30 UTC ]] (4pm IST, 12:30 CEST, 3:30 PST) in `#wikimedia-ect` IRC. URL of web proxy of Labs instance where development takes place : http://newsletter-test.wmflabs.org/ == Plan == === Readers === * **A catalog of newsletters in one multilingual wiki** (Meta). Let's start defining a single translatable location to find all the newsletters. Meta is the logical choice. No matter which project the newsletter authors come from, all of them would create and organize their newsletters in a common location. * Easy subscription. As a logged-in user, click a button. As anonymous user, log in or create an account. (Ideally just entering an email address would work too, with confirmation). Question: should an email address in your profile be required? Can this be checked? Echo probably has solved this. * A notification is received when a new issue is published. Notifications are handled via Echo, and therefore they can be received via web or email according to user preferences. * Easy to unsubscribe. As a logged-in user, click a button. Accessing a URL from notifications should unsubscribe you as well, after confirmation. * Usernames and emails of subscribes should be kept private. The number of users subscribed to a newsletter would be public (and eventually used to promote popular newsletters). === Publishers === * A process defining the conditions in which a newsletter can be created, featured, demoted, closed (actions that might imply database changes). Just a basic framework to promote best practices and prevent abuse. * Once a newsletter is created, maintaining the content (homepage, subpages) could be done in a plain wiki way for creating pages, watching, editing, reverting, protecting if needed... New content is in practice a draft, since it hasn't been announced to the subscribers. Whoever wants to watch changes can read the drafts and get involved. * Once a new issue (a page) is ready, the owners of the newsletter send a notification. This requires special permissions. **Permissions** Any autoconfirmed user can become a publisher - create newsletters, announce issues, manage newsletters because of two particular reasons ( quoting Quim ): # Autoconfirmed users can create newsletter pages and issues anyway (even anonymous can). # Even if a publisher were to cause any kind of damage it will affect popularity of their newsletters as well. The extension takes care of subscriptions to the newsletter and notifications from newsletters and hence the creation of newsletters and issues are external to our extension. === Newsletters === A newsletter generally has one or more of the following properties (some newsletters have more of these than others): * Home page: a page that contains information about the newsletter and what it contains * Current issue page: self-explanatory * Archive pages: past editions of the newsletter that were previously published * Authors / Editors: a group of people that are allowed and/or expected to contribute content * Publishers: a group of people that are allowed to finalize an edition and publish it to readers Most likely, showing a user (on the preferences page mentioned above) a link to the home page, a description of the newsletter, and maybe a link to the current issue and archive pages would be useful. As mentioned in a comment below, it would probably be best to shift management of authors and editors to the existing page protection feature, i.e., if the newsletter really needs to be protected from unauthorized editing, make a restriction level and assign authors the necessary permission. Publishers would probably need separate management, and would probably be maintained in the same interface that information about the newsletter itself is maintained. ===Backend=== Check this Etherpad entry on discussions with hoo: https://etherpad.wikimedia.org/p/newsletterExtension While discussing with other developers, we realized there are two options for the extension's backend architecture - either use Contenthandlers or use Database( sql tables ). As of now while we prepare the patches for MVP, the database approach is taken. To choose the best for the extension out of all available options at it's earliest stages of development would be the apt thing to do, hence opening up this section for further discussions. === See also === * https://www.mediawiki.org/wiki/Extension:Newsletter * https://meta.wikimedia.org/wiki/Grants:IdeaLab/Newsletter_extension_for_MediaWiki ===Proposed Schedule=== | **Tasks to be completed **|**Timeline**|**Remarks**| |Create Wikimedia Labs project, create instance, community bonding| 28/03/15 - 30/04/15| Created Labs project 'newsletter' and instance, 'newsletter-test'. Successfully ssh-ed to the instance| |Decide on MVP plan and create necessary tasks|01/05/15 - 05/05/15|Done | |Create the Special:NewsLetterCreate interface, and design DB ( the new table )| 06/05/15 - 10/05/15|Done | |Create the Special:NewsLetterManage interface - Publisher's view, Newsletter skeleton| 20/05/15 - 30/05/15|Done | |Create Special:Newsletters and deploying features on vagrant| 31/05/15 - 15/06/15|Done | |Adding newsletter in Notifications tab of Special:Preferences and completing T101546| 16/06/15 - 24/06/15|Done | | Mid Term Evaluation| 26/06/15 - 03/07/15|Done | | Work on Blockers and complete extension considering case of Meta alone and no inter wiki newsletters| 04/07/15 - 20/07/15|Done | | Work on T102945, T101832, T104829| 21/07/15 - 10/08/15|Done | | Writing unit tests, testing the work flow, documentation, deployment | 11/08/15 - 20/08/15|Done| | Final Report Submission| 21/08/2015|Done |

NOTE: This Google Summer of Code project has been completed successfully. Thank you @tinaj1234 for your contributions, and thank you @01tonythomas for your technical mentoring. This team has worked very well so far! For details, read {T109288}. The work continues at {T110170}. As always, your feedback and contributions are welcome. This is not an internship project anymore; patches are very welcome. :) == Newsletter extension == An extension allowing publishers to create newsletters and announce new issues, and allowing users to browse and subscribe to newsletters. A #Google-Summer-of-Code-2015 project lead by @tinaj1234, mentored by @01tonythomas and @qgil. Currently working on {T99784} and blockers. Weekly reports: T100997 Weekly meetings: every [[ http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150605T1030 | Thursday at 10:30 UTC ]] (4pm IST, 12:30 CEST, 3:30 PST) in `#wikimedia-ect` IRC. URL of web proxy of Labs instance where development takes place : http://newsletter-test.wmflabs.org/ == Plan == === Readers === * **A catalog of newsletters in one multilingual wiki** (Meta). Let's start defining a single translatable location to find all the newsletters. Meta is the logical choice. No matter which project the newsletter authors come from, all of them would create and organize their newsletters in a common location. * Easy subscription. As a logged-in user, click a button. As anonymous user, log in or create an account. (Ideally just entering an email address would work too, with confirmation). Question: should an email address in your profile be required? Can this be checked? Echo probably has solved this. * A notification is received when a new issue is published. Notifications are handled via Echo, and therefore they can be received via web or email according to user preferences. * Easy to unsubscribe. As a logged-in user, click a button. Accessing a URL from notifications should unsubscribe you as well, after confirmation. * Usernames and emails of subscribes should be kept private. The number of users subscribed to a newsletter would be public (and eventually used to promote popular newsletters). === Publishers === * A process defining the conditions in which a newsletter can be created, featured, demoted, closed (actions that might imply database changes). Just a basic framework to promote best practices and prevent abuse. * Once a newsletter is created, maintaining the content (homepage, subpages) could be done in a plain wiki way for creating pages, watching, editing, reverting, protecting if needed... New content is in practice a draft, since it hasn't been announced to the subscribers. Whoever wants to watch changes can read the drafts and get involved. * Once a new issue (a page) is ready, the owners of the newsletter send a notification. This requires special permissions. **Permissions** Any autoconfirmed user can become a publisher - create newsletters, announce issues, manage newsletters because of two particular reasons ( quoting Quim ): # Autoconfirmed users can create newsletter pages and issues anyway (even anonymous can). # Even if a publisher were to cause any kind of damage it will affect popularity of their newsletters as well. The extension takes care of subscriptions to the newsletter and notifications from newsletters and hence the creation of newsletters and issues are external to our extension. === Newsletters === A newsletter generally has one or more of the following properties (some newsletters have more of these than others): * Home page: a page that contains information about the newsletter and what it contains * Current issue page: self-explanatory * Archive pages: past editions of the newsletter that were previously published * Authors / Editors: a group of people that are allowed and/or expected to contribute content * Publishers: a group of people that are allowed to finalize an edition and publish it to readers Most likely, showing a user (on the preferences page mentioned above) a link to the home page, a description of the newsletter, and maybe a link to the current issue and archive pages would be useful. As mentioned in a comment below, it would probably be best to shift management of authors and editors to the existing page protection feature, i.e., if the newsletter really needs to be protected from unauthorized editing, make a restriction level and assign authors the necessary permission. Publishers would probably need separate management, and would probably be maintained in the same interface that information about the newsletter itself is maintained. ===Backend=== Check this Etherpad entry on discussions with hoo: https://etherpad.wikimedia.org/p/newsletterExtension While discussing with other developers, we realized there are two options for the extension's backend architecture - either use Contenthandlers or use Database( sql tables ). As of now while we prepare the patches for MVP, the database approach is taken. To choose the best for the extension out of all available options at it's earliest stages of development would be the apt thing to do, hence opening up this section for further discussions. === See also === * https://www.mediawiki.org/wiki/Extension:Newsletter * https://meta.wikimedia.org/wiki/Grants:IdeaLab/Newsletter_extension_for_MediaWiki ===Proposed Schedule=== | **Tasks to be completed **|**Timeline**|**Remarks**| |Create Wikimedia Labs project, create instance, community bonding| 28/03/15 - 30/04/15| Created Labs project 'newsletter' and instance, 'newsletter-test'. Successfully ssh-ed to the instance| |Decide on MVP plan and create necessary tasks|01/05/15 - 05/05/15|Done | |Create the Special:NewsLetterCreate interface, and design DB ( the new table )| 06/05/15 - 10/05/15|Done | |Create the Special:NewsLetterManage interface - Publisher's view, Newsletter skeleton| 20/05/15 - 30/05/15|Done | |Create Special:Newsletters and deploying features on vagrant| 31/05/15 - 15/06/15|Done | |Adding newsletter in Notifications tab of Special:Preferences and completing T101546| 16/06/15 - 24/06/15|Done | | Mid Term Evaluation| 26/06/15 - 03/07/15|Done | | Work on Blockers and complete extension considering case of Meta alone and no inter wiki newsletters| 04/07/15 - 20/07/15|Done | | Work on T102945, T101832, T104829| 21/07/15 - 10/08/15|Done | | Writing unit tests, testing the work flow, documentation, deployment | 11/08/15 - 20/08/15|Continuing |Done| | Final Report Submission| 21/08/2015|Pending |Done |