Change Details

**Abstract** Until now Wikimedia projects have a hard time communicating their activity across the movement and out there relying on watching pages, subscribing to mailing lists, follow blogs and social media. For most users, managing all these channels is hard, and every option includes exposure to plenty of noise. To solve this problem newsletters seems the most appropriate tool. The goal of this project is to completely finish the Newsletters MediaWiki extension. **1. Personal Information** **Name:** Victoria Jiménez González **E-mail address**: vicky@altermundi.net **IRC username:** zenemij **@phafricator: **vickyjim5 **@retroshare:** zenemij **@github**: zenem **Location:** Barcelona (Spain) **Typical working hours:** 40 hours/week **Brief background:** I have recently completed Aerospace Engineering and I am student of Electronic Engineering right now, as hobby I have studied about web development and design, so I know HTML, CSS, JavaScript and various web development technology such as JQuery and AJAX, while I have basic knowledge of SQL, Python and PHP. **How did you hear about this program?** I heard about GSoC by participating at Don't Panic Hacklab in Barcelona **2. Project Information** **Project title:** Newsletter extension for MediaWiki ** Possible mentors:** Tony Thomas and Quim Gil ** Detailed project description:** In a MediaWiki context, "a newsletter" can just be a main page with subpages for every issue or article. This part of the problem is well solved. The current functionalities of the Newsletters extension are: 1. Users with autoconfirmed email can subscribe/unsubscribe to a single newsletter via Preferences > Email options. 2. Admins with access to the database can collect manually the email addresses of the users subscribed. The missing piece is the possibility to discover newsletters and subscribe to them in order to receive notifications.The extension would have two genre of users: 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. An email notification is received when a new issue is published. It is probably easy to offer web notifications only as well, but email is the main use case. Easy to unsubscribe. As a logged-in user, click a button. Accessing a URL from the email 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. The newsletter will have at least the following properties: 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 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. 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. **Development schedule:** **Community Bounding (April 27 - May 25)** Interact with the mentors and developers on IRC, Phabricator and mailing lists. Establish and clarify the needs of the community related to the project. Familiarization with Phabricator to use it as diffusion media of the progress of the project. **Students Coding (May 25 - August 24)** **Front End - Web interface (May 25 - 29 June 26)** Reader web interface mockup Publisher web interface mockup Initial coding **Back End - MySQL (June 1 - July 17 )** Investigation Database Design Coding Testing and debugging Write documentation **Front End - Web interface (July 20 - August 24)** Reader web interface coding Publisher web interface coding Testing, debugging and final refinement Make documentation Describe time availability: For first time since long time I will have a lot of free time during the summer so I will assume 40 hours/week. Anyway, I am determined to finish completely the project so I will dedicated more hours if it is needed to get my goal on time. **Why I am interested in WikiMedia community?** Because I am a MediaWiki user and I want to help to improve free and open source software. I love FOSS and I consider it very important to human society and culture improvement. Usually I don't have time to contribute to Wikimedia because of my studies or due to work for paying rent, bills and food. It is amazing for me contribute to a FOSS community and have remuneration for it. Especially for a community that gave me a lot due to I am a addicted to Wikipedia. **Why I would be a good candidate?** Because I have basic technical knowledge to develop the project and I am willing to expand them. I have also experience in community development because I contribute since several years in different communities related with mesh networks such as guifi.net. Overcoat I am very motivated to complete this project and working on it will give me the knowledge and confidence for a long time cooperation with WikiMedia community also after the GSoC ends. **Something else:** I am very enthusiasm of taking this project. I can assure that if I take the compromise of doing a project I will do it. I never gave up on any project I took in my life. For me is very important this project also because it can give me the possibility enrich me as human and as a web developer which is a long time desire for me.

**Abstract** Until now Wikimedia projects have a hard time communicating their activity across the movement and out there relying on watching pages, subscribing to mailing lists, follow blogs and social media. For most users, managing all these channels is hard, and every option includes exposure to plenty of noise. To solve this problem newsletters seems the most appropriate tool. The goal of this project is to completely finish the Newsletters MediaWiki extension. **1. Personal Information** **Name:** Victoria Jiménez González **E-mail address**: vicky@altermundi.net **IRC username:** zenemij **@phafricator: **vickyjim5 **@retroshare:** zenemij **@github**: zenem **Location:** Barcelona (Spain) **Typical working hours:** 40 hours/week **Brief background:** I have recently completed Aerospace Engineering and I am student of Electronic Engineering right now, as hobby I have studied about web development and design, so I know HTML, CSS, JavaScript and various web development technology such as JQuery and AJAX, while I have basic knowledge of SQL, Python and PHP. **How did you hear about this program?** I heard about GSoC by participating at Don't Panic Hacklab in Barcelona **2. Project Information** **Project title:** Newsletter extension for MediaWiki ** Possible mentors:** Tony Thomas and Quim Gil ** Detailed project description:** In a MediaWiki context, "a newsletter" can just be a main page with subpages for every issue or article. This part of the problem is well solved. The current functionalities of the Newsletters extension are: 1. Users with autoconfirmed email can subscribe/unsubscribe to a single newsletter via Preferences > Email options. 2. Admins with access to the database can collect manually the email addresses of the users subscribed. The missing piece is the possibility to discover newsletters and subscribe to them in order to receive notifications.The extension would have two genre of users: **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. An email notification is received when a new issue is published. It is probably easy to offer web notifications only as well, but email is the main use case. Easy to unsubscribe. As a logged-in user, click a button. Accessing a URL from the email 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. The newsletter will have at least the following properties: 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 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. 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. **Development schedule:** **Community Bounding (April 27 - May 25)** Interact with the mentors and developers on IRC, Phabricator and mailing lists. Establish and clarify the needs of the community related to the project. Familiarization with Phabricator to use it as diffusion media of the progress of the project. **Students Coding (May 25 - August 24)** **Front End - Web interface (May 25 - 29 June 26)** Reader web interface mockup Publisher web interface mockup Initial coding **Back End - MySQL (June 1 - July 17 )** Investigation Database Design Coding Testing and debugging Write documentation **Front End - Web interface (July 20 - August 24)** Reader web interface coding Publisher web interface coding Testing, debugging and final refinement Make documentation Describe time availability: For first time since long time I will have a lot of free time during the summer so I will assume 40 hours/week. Anyway, I am determined to finish completely the project so I will dedicated more hours if it is needed to get my goal on time. **Why I am interested in WikiMedia community?** Because I am a MediaWiki user and I want to help to improve free and open source software. I love FOSS and I consider it very important to human society and culture improvement. Usually I don't have time to contribute to Wikimedia because of my studies or due to work for paying rent, bills and food. It is amazing for me contribute to a FOSS community and have remuneration for it. Especially for a community that gave me a lot due to I am a addicted to Wikipedia. **Why I would be a good candidate?** Because I have basic technical knowledge to develop the project and I am willing to expand them. I have also experience in community development because I contribute since several years in different communities related with mesh networks such as guifi.net. Overcoat I am very motivated to complete this project and working on it will give me the knowledge and confidence for a long time cooperation with WikiMedia community also after the GSoC ends. **Something else:** I am very enthusiasm of taking this project. I can assure that if I take the compromise of doing a project I will do it. I never gave up on any project I took in my life. For me is very important this project also because it can give me the possibility enrich me as human and as a web developer which is a long time desire for me.

**Abstract** Until now Wikimedia projects have a hard time communicating their activity across the movement and out there relying on watching pages, subscribing to mailing lists, follow blogs and social media. For most users, managing all these channels is hard, and every option includes exposure to plenty of noise. To solve this problem newsletters seems the most appropriate tool. The goal of this project is to completely finish the Newsletters MediaWiki extension. **1. Personal Information** **Name:** Victoria Jiménez González **E-mail address**: vicky@altermundi.net **IRC username:** zenemij **@phafricator: **vickyjim5 **@retroshare:** zenemij **@github**: zenem **Location:** Barcelona (Spain) **Typical working hours:** 40 hours/week **Brief background:** I have recently completed Aerospace Engineering and I am student of Electronic Engineering right now, as hobby I have studied about web development and design, so I know HTML, CSS, JavaScript and various web development technology such as JQuery and AJAX, while I have basic knowledge of SQL, Python and PHP. **How did you hear about this program?** I heard about GSoC by participating at Don't Panic Hacklab in Barcelona **2. Project Information** **Project title:** Newsletter extension for MediaWiki ** Possible mentors:** Tony Thomas and Quim Gil ** Detailed project description:** In a MediaWiki context, "a newsletter" can just be a main page with subpages for every issue or article. This part of the problem is well solved. The current functionalities of the Newsletters extension are: 1. Users with autoconfirmed email can subscribe/unsubscribe to a single newsletter via Preferences > Email options. 2. Admins with access to the database can collect manually the email addresses of the users subscribed. The missing piece is the possibility to discover newsletters and subscribe to them in order to receive notifications.The extension would have two genre of users: **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. An email notification is received when a new issue is published. It is probably easy to offer web notifications only as well, but email is the main use case. Easy to unsubscribe. As a logged-in user, click a button. Accessing a URL from the email 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. The newsletter will have at least the following properties: 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 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. 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. **Development schedule:** **Community Bounding (April 27 - May 25)** Interact with the mentors and developers on IRC, Phabricator and mailing lists. Establish and clarify the needs of the community related to the project. Familiarization with Phabricator to use it as diffusion media of the progress of the project. **Students Coding (May 25 - August 24)** **Front End - Web interface (May 25 - 29 June 26)** Reader web interface mockup Publisher web interface mockup Initial coding **Back End - MySQL (June 1 - July 17 )** Investigation Database Design Coding Testing and debugging Write documentation **Front End - Web interface (July 20 - August 24)** Reader web interface coding Publisher web interface coding Testing, debugging and final refinement Make documentation Describe time availability: For first time since long time I will have a lot of free time during the summer so I will assume 40 hours/week. Anyway, I am determined to finish completely the project so I will dedicated more hours if it is needed to get my goal on time. **Why I am interested in WikiMedia community?** Because I am a MediaWiki user and I want to help to improve free and open source software. I love FOSS and I consider it very important to human society and culture improvement. Usually I don't have time to contribute to Wikimedia because of my studies or due to work for paying rent, bills and food. It is amazing for me contribute to a FOSS community and have remuneration for it. Especially for a community that gave me a lot due to I am a addicted to Wikipedia. **Why I would be a good candidate?** Because I have basic technical knowledge to develop the project and I am willing to expand them. I have also experience in community development because I contribute since several years in different communities related with mesh networks such as guifi.net. Overcoat I am very motivated to complete this project and working on it will give me the knowledge and confidence for a long time cooperation with WikiMedia community also after the GSoC ends. **Something else:** I am very enthusiasm of taking this project. I can assure that if I take the compromise of doing a project I will do it. I never gave up on any project I took in my life. For me is very important this project also because it can give me the possibility enrich me as human and as a web developer which is a long time desire for me.