Since the MVP is completed we are in position to discuss on our next milestone!

You can see a number of blockers listed in MediaWiki-extensions-Newsletter workboard. But we think there is a possibility for more blockers and if anyone finds one feel free to create a task and add it to the workboard. The blockers to be closed by end of July will be decided on the next week's meeting ( 9th June 10:30 AM UTC ) and it would be convenient to have all the blockers out by then.

Test MVP here: http://newsletter-test.wmflabs.org/ ( Check description on Main Page to find which page to go to )

@Quiddity, @Bawolff, @Legoktm Awaiting reviews and comments especially from you guys :)

The criteria to define a blocker should be:

Bugfix or feature required to handle newsletters hosted in Meta.

Let's leave the multi-wiki scenario for the next milestone (hopefully to be still address during this GSoC round, will depend on the blockers for the single wiki scenario).

I tested it a bit. Looking good so far! I do wonder if a short tagline could not be added to the Echo notification (something along the lines of "In this issue: see what really goes in the Phabricator"), but other than that it's already a dream come true.

In T76199#1428602, @ResMar wrote:

I do wonder if a short tagline could not be added to the Echo notification (something along the lines of "In this issue: see what really goes in the Phabricator")

Yes, it would be more informative for the readers if the notification can contain more details indicating what the new issue is about. Thank you! I'll add a blocker task for this.

Hello!

End of GSoC is fast approaching. 17 August is "Suggested pencils down" deadline and 21 August is "Firm pencils down" deadline. It is expected that you don't dive into new features which might take longer than two weeks to complete and instead work on polishing up your project, testing thoroughly and getting your code merged into the main branch. I hope this project is almost complete so you can merge it and make it available to everyone as quickly as possible. :)

A few questions (for both mentors and student):

• Are you confident in completing the project on time?
• By when do you think you can merge the code, if at all?
• Are there any major blockers or important missing features?

We are looking for projects which are (nearly) complete to feature on our post on Wikimedia and Google OSPO's blogs (for example: http://google-opensource.blogspot.in/2015/02/google-summer-of-code-wrap-up-processing.html). If you're interested in getting yours up there, hurry up and get this finished!

The hard deadline on getting code merged is September. T101393: Goal: All completed GSoC and Outreachy projects have code merged and deployed by September for details.

We'll be asking the students to demo their projects towards the end of the program as well.

Good luck!

In T76199#1514646, @NiharikaKohli wrote:

A few questions (for both mentors and student):

• Are you confident in completing the project on time?

Yes, ofcourse.

• By when do you think you can merge the code, if at all?

Most of the completed features are merged already. Everything will be merged before 17th August.

• Are there any major blockers or important missing features?

No, all important features are almost done. Remaining high priority tasks will be completed in the coming week.

In T76199#1514646, @NiharikaKohli wrote:

A few questions (for both mentors and student):

• Are you confident in completing the project on time?

Of course. Almost all the blockers are resolved as of now, and looking at the open tasks at https://phabricator.wikimedia.org/T76199 - its more of the design elements still there. The strictly planned MVP which came as a result of discussions from Lyon and weekly meetings made sure that we have the minimum features ready even before mid-term. This made it easy for @Tinaj1234, as most of the post-mid term works were design stuff. Most features lacked documentation, but @Tinaj1234 was impressive with getting it done.

• By when do you think you can merge the code, if at all?

Almost all of the patchsets that showed up in Gerrit was reviewed and merged to the github repo in < 2 days - and if you are talking about deployment to production, it might take a bit long to go through the security, arch and performance review through beta to prod - and I expect these to happen in the coming month. Deployment to production was not a part of the GSoC project, anyway.

• Are there any major blockers or important missing features?

I dont think there is anything critical as of now.

Great work till date. You can see the code produced over here : https://github.com/wikimedia/mediawiki-extensions-Newsletter, and test it live at newsletter-test.wmflabs.org

In our case, "merged" is what exists in the Newsletter extension repo, fully functional in Labs. "Deployed in Wikimedia" is a goal for us, but definitely out of scope of GSoC.

It would be great if you could import the repo to Gerrit instead of working off of github.

In T76199#1528553, @Dzahn wrote:

It would be great if you could import the repo to Gerrit instead of working off of github.

Ah. We were committing to Gerrit from the start of the project. We have it over here http://git.wikimedia.org/tree/mediawiki%2Fextensions%2FNewsletter

Great. @Tinaj1234, please write up a short description of the project when you get time for the blog. Also add one, most relevant screenshot which I can include in the post. Thanks!

Hi, I have associated two blocked-by tasks with this project.

For the student:

1. Please go through the checklist in the end-term evaluation and fill out the fields which require any links. The checkboxes are for the mentor(s) only. Adding information on the past projects page is your task.
2. Ensure that you have completed all the items listed in the end-term evaluation task. If there's a strong reason about why a particular item was not completed, please comment on the task and we shall look into it.
3. Wrap-up report is mandatory and so is a demo-able link to the project (either in production or in a demo server).
4. If you want your project to be featured in the blogpost on the Google OSPO blog, kindly comment back with a short, catchy description of the project along with a screenshot.

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

I do not see a reason for this.

I believe @Qgil was referring to the case of http://newsletter-test.wmflabs.org/wiki/Special:Newsletters where a user need not know who is subscribed to the newsletter instead we tell him/her the popularity of the newsletter through the subscriber count.

Reading this plan, no publisher is able to give feedback as the actual contents are missing. The actual things that matter to publishers is not described in the plan. The plan described is too vague.

It is like describing a new car: it has doors, a steering wheel, seets, a roof, lights and more. This is completely insufficient.

Also some other issues:

• Where there any publishers and readers involved in the plan?
• Has there been any priority check for which software developments are really needed and make a big difference for the movement?
• Where there any publishers and readers involved during the development process?

Reading more pages I get the impression that these three questions are to be answered with "no".

Seeing what problem description is given, I can only think it is too simplistic and not reaching to the core of the problem:

• MediaWiki is not designed for global navigation, nor navigation across wikis.
• the MediaWiki software is very primitive - it is for example not possible to create a simple button in what someone can (un)subscribe or one of the many other limitations that prevent it to be easy.

Instead of improving this limited and too often too difficult situation, effort is taken to fight only a symptom of the core problems.

I am afraid that this extension appears to be a waste of energy and resources.

In T76199#1564783, @Romaine wrote:

Reading this plan, no publisher is able to give feedback as the actual contents are missing. The actual things that matter to publishers is not described in the plan. The plan described is too vague.

It is like describing a new car: it has doors, a steering wheel, seets, a roof, lights and more. This is completely insufficient.

I don't think the plan ( which was worked upon for 4-5 months and was open to anyone interested ) is insufficient at all. The extension pretty much makes easy any task a publisher or an owner is required to do. Please go through the features implemented as well because the extension has evolved very much from its initial stages.

Also some other issues:

• Where there any publishers and readers involved in the plan?
• Has there been any priority check for which software developments are really needed and make a big difference for the movement?
• Where there any publishers and readers involved during the development process?

Reading more pages I get the impression that these three questions are to be answered with "no".

The answer is a 'yes'. I see you've gone through T100604 and we waited over a week before closing that task to collect reviews and opinions of stakeholders. A message was left on each page( the list of links in T100604 ) to inform existing newsletters and various other developers about the extension and we were encouraged by a lot of positive replies from many editors and publishers to move forward with the extension.

Seeing what problem description is given, I can only think it is too simplistic and not reaching to the core of the problem:

• MediaWiki is not designed for global navigation, nor navigation across wikis.
• the MediaWiki software is very primitive - it is for example not possible to create a simple button in what someone can (un)subscribe or one of the many other limitations that prevent it to be easy.

I don't quite get what you meant here. But we have brought up a beautiful extension which works fine( with tables and buttons and what not ) and is believed to benefit many, do have a look.

4-5 months

We received a message only 2 months ago: 9 June 2015. Just before the most busiest time of the year.

I don't think the plan [...] is insufficient at all.

Reading the plan, as described in the first post in this Task, it is insufficient to judge.

The answer is a 'yes'.

I doubt that. I think the difference in answering is likely caused by interpreting the questions differently than how they were intended.

I am not necessary negative about the idea, but the plan described in post 1 is insufficient. And the involvement from stakeholders was also insufficient. (Yes, insufficient with the current level of participation.)
Based on the provided information I get too much the idea that this extension is developed for instead of developed with. Of course you then say that you have asked newsletter to give feedback, but that makes it still insufficient. The biggest pain in the ass for the Wikimedia community is that they are too little considered to be stakeholder, and are to little involved from the first plan until the end during the whole process.

I don't quite get what you meant here.

I described two large issues we experience working on wikis too often. The problem description on Meta can be completely derived from these two large issues. This makes "fixing" the described problem a form of treating symptoms, instead of the core problems.

It gives me this feeling: https://xkcd.com/927/

But we have brought up a beautiful extension which works fine( with tables and buttons and what not ) and is believed to benefit many, do have a look.

This sounds like a car salesman. I do not think it is a good idea if a developer him/herself is saying that it is beautiful, fine working, benefit many, etc. That is up to the stake holders and end users to judge.

(Please remember that this bug is about developing a newsletter extension for *MediaWiki*, not *Wikimedia*.)

I think that Romaine is implicitly criticizing a problem that's plagued the movement for a long time: outside contractors are brought in, write a feature, and then leave. No offense to you, Tinaj, but I highly doubt that say three years from now you will be maintaining this codebase, or even contactable.

In your absence no one attached to the movement will be familiar with the code, causing it to trip up other extensions, suffer legacy rot, and eventually become completely unusable. This turnover problem is one half of the legacy dependence problem of the Wikimedias (a total lack of intercommunal standards across Wikimedias is the other half).

In this case the extension backs into a "platform for the future", Echo, that's in continual development. Hopefully that will keep this extension alive.

Thanks ResMar!
What ResMar is describing is indeed a part of the issue I see. I am concerned about both the process of the development of this software as the general situation of software development. I am concerned about a long term stability.

Can someone briefly explain the goal of this project? From the title and description, it sounds like a project to create a new extension. But instead, this project seems to have modified an existing extension, "Newsletter". Is that the case? If so, did the task change at some point? And what is the goal that was achieved?

In T76199#1566284, @Yaron_Koren wrote:

Can someone briefly explain the goal of this project? From the title and description, it sounds like a project to create a new extension. But instead, this project seems to have modified an existing extension, "Newsletter". Is that the case? If so, did the task change at some point? And what is the goal that was achieved?

The goal of the project was to build a 'Newsletter' extension which must allow:

1. Newsletter Authors to easily create and manage Newsletters with scope limited to his rights
2. A usual wiki user to subscribe/unsubscribe to available newsletters in his Wiki ( inter-wiki is post GSoC scope )
3. Receive notifications via web/email using Echo whenever a Newsletter creates a new issuse.

The project took place basically from the description of this task, and was built from scratch ( https://github.com/wikimedia/mediawiki-extensions-Newsletter/commits/master ) - now live at http://newsletter-test.wmflabs.org/wiki/Main_Page - You can find the instructions on how to use the same over there. @Tinaj1234 will work on it further to cross the arch/sec and performance review to take it to production which is of course, not in the scope of GSoC 2015.

In T76199#1566016, @ResMar wrote:

I think that Romaine is implicitly criticizing a problem that's plagued the movement for a long time: outside contractors are brought in, write a feature, and then leave. No offense to you, Tinaj, but I highly doubt that say three years from now you will be maintaining this codebase, or even contactable.

Just for the record, there are several developers who had GSOC projects and stuck around for 3 or more years. I have no idea if Tinaj will be one of them, and s/he certainly has no obligations past the end of his/her project but its entirely possible that s/he could be.

In your absence no one attached to the movement will be familiar with the code, causing it to trip up other extensions, suffer legacy rot, and eventually become completely unusable. This turnover problem is one half of the legacy dependence problem of the Wikimedias (a total lack of intercommunal standards across Wikimedias is the other half).

In this case the extension backs into a "platform for the future", Echo, that's in continual development. Hopefully that will keep this extension alive.

I'm not sure its fair to have this discussion here. These sound more like generic issues surrounding the GSOC/OPW program and doesn't have much to do with this particular project.

Keep in mind, creating a feature for use by the Wikimedia movement over the long term is not necessarily the goal of the GSOC/OPW program.

@Romaine, @ResMar, here goes some background and a request to be respectful with the open and documented work that others are doing. The summary is: I think this project and its lead developer don't deserve the tone of your first posts here, feel free to learn and ask about the steps we have done, and by all means please bring all the specific objections you might have about this project.

Since 2013, I have been advocating for a newsletter type of functionality for MediaWiki, to be deployed in Wikimedia servers (if you want me to dig in wikitech-l archives, I will). Anybody working on a project in our context knows about the difficulty of setting up one-to-many communications with regular Internet users, not necessarily familiar with watching pages (and following watchlists) or subscribing to services MassMessage style.

https://www.mediawiki.org/wiki/Extension:Newsletter was created on 10 September 2013‎, after I proposed @siebrand to fork the code related to notifications in the Translate extension. That path didn't progress further.

After some discussions in the context of MassMessage tasks, it was clear that that project would not be the solution for this use case. In 28 November 2014 I created this task.

The rest can be read in this task. On 10 February 2015 I proposed it as a Possible-Tech-Projects, and from that point it entered the community review process. @01tonythomas (a former GSoC student, sticking around) volunteered as technical mentor. @Tinaj1234 stepped in as a Google Summer of Code candidate, together with several other students. Tina was selected, and we started to work following the GSoC deadlines. We had a couple of scheduled sessions at the Wikimedia Hackathon in Lyon on May, in June we contacted all the newsletter admins we found in several Wikimedia projects...

I'm sorry you received such notifications in your busiest time, but I hope you understand that we cannot wait for the best spot in everybody's agendas. In terms of communication and feedback, I think we have covered the minimum and more.

As of today this GSoC project is actually completed, awaiting only its evaluation. We are already discussing the next steps, which include addressing the open tasks, and go through the process to have this extension deployed in Beta, Meta, and then we'll see. Even if you just joined the discussion now, you still have time and chances to bring your feedback and objections.

This is about the project. Now let me add something about the developer that has put hundreds of hours on it in the past months. @Romaine @ResMar, our new developers deserve a welcoming attitude from all of us. Especially when they are volunteers and interns in programs like GSoC, where Wikimedia decides to participate with a tailored community review process. Nobody knows whether these newcomers will be around in three years. And by the way, the same could be said about all of us (yourselves included) when we joined, and still today.

But you know what? In this specific case it is not even accurate to call @Tinaj1234 a newcomer. Her first patches for Wikimedia were uploaded on December 2013 and since then she has got code merged in MediaWiki core and some extensions. She has a user account in mediawiki.org since February 2014, when she started to prepare a GSoC proposal. She wasn't accepted because another candidate was chosen for the same project instead (@wctaiwan, who is another example of a GSoC student sticking around until today). So really, Tina has shown a remarkable level of commitment and perseverance even before the end of her GSoC internship.

In T76199#1564774, @Romaine wrote:

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

I do not see a reason for this.

User expectations, user privacy. It is a usual practice in the Internet that only admins of a newsletter can see who is subscribed to it. For what is worth, by default Wikimedia mailing lists don't disclose the identity of their subscribers either, and only their admins can access to this data.

User expectations, user privacy.

Those are choices. Here it is chosen to give users privacy. I think it is thought too easy about this.

It is a usual practice in the Internet that only admins of a newsletter can see who is subscribed to it. For what is worth, by default Wikimedia mailing lists don't disclose the identity of their subscribers either, and only their admins can access to this data.

It is a usual practice thanks to Twitter and other social media that it is publicly known who is watching what. The comparison with mailing lists is not accurate enough imo.

I'm sorry you received such notifications in your busiest time, but I hope you understand that we cannot wait for the best spot in everybody's agendas. In terms of communication and feedback, I think we have covered the minimum and more.

That was not my point. It reacted on this:

worked upon for 4-5 months and was open to anyone interested

But only 2 months time was actually given to react.

As said before, I am especially disappointed in the problem definition and how the plan in post 1 is described. I gave feedback on that. I have described problems in the process, but I do not get the impression that it is taken seriously.

@Tinaj1234 & @01tonythomas My apologies to you both if my messages are unpleasant. The problems I notice are outside your involvement in this project (so far I understand). I am personally concerned about how the resources (like you) are used in software development. So please do not take this as criticism on your work, so far I can see you have done in the given circumstances a great job.

In the Internet most newsletters have a private list of subscribers. If you want to discuss this topic further, please create a new task.

Google Summer of Code has strict deadlines. Projects have to deliver functional code in less than four months. We cannot spend half of that time waiting for feedback without writing any code.

On resources, Tina is a volunteer receiving a stipend from Google, Tony is volunteering as primary mentor, and I'm dedicating about 1-2 hours/week as secondary mentor. Other people has been involved in this project in a smaller capacity, most of them by personal initiative and as volunteers.

I have re-read your comments above, and I still don't see which specific problems can we address. You say

• MediaWiki is not designed for global navigation, nor navigation across wikis.

I'm not sure what that means, but in any case this extension is not read for interwiki use today. This was left out of scope for the GSoC project and needs to be revisited now.

• the MediaWiki software is very primitive - it is for example not possible to create a simple button in what someone can (un)subscribe or one of the many other limitations that prevent it to be easy.

This extension allows users to subscribe and unsubscribe from newsletters using checkboxes.

Again, you are encouraged to file tasks for specific problems.

@01tonythomas - when you say "built from scratch", does that mean that the old extension code was simply wiped out? Looking at the mediawiki.org page, it doesn't look that way - Siebrand is still listed as the author of the extension.

In T76199#1568209, @Yaron_Koren wrote:

@01tonythomas - when you say "built from scratch", does that mean that the old extension code was simply wiped out? Looking at the mediawiki.org page, it doesn't look that way - Siebrand is still listed as the author of the extension.

Yeah - the first commit by @Tinaj1234 wiped out everything ( https://github.com/wikimedia/mediawiki-extensions-Newsletter/commit/f0e8491e0c1abda0117b67f05db42fbc708568ca ) if you ignore $wgExtensionCredits entries in Newsletter.php :). Since @siebrand made an inital commit of the extension in https://github.com/wikimedia/mediawiki-extensions-Newsletter/commit/8cf079a2c2cb71670728eef36c9e42ccbff077be back in 2013 - I think @Tinaj1234 wants to give him credit for his work - which is perfect.

@01tonythomas - okay, thanks, that's helpful. I don't know if giving someone credit for code he didn't write is "perfect" - it could confuse people (at least, it confused me). Those credits, like the "author" field in mediawiki.org infoboxes, are not just there to give respect; they also give helpful information, like whom to contact if you're thinking of submitting a patch. What about adding a "History" section to the mediawiki.org page, to be able to credit Siebrand while clarifying the current situation?

For what is worth, T108205: Newsletter extension: Complete Documentation is still open, to be closed this week.

Ohh

@Qgil Unlike communications interns, tech interns create products that the community has to rely on in the long term. But will the Foundation commit to maintaining this extension in the long term?

In general, no (you say "that's not the point"). In this particular case, I believe yes, because several Foundation-led efforts---the Research Newsletter and Tech/News---will come to rely on it. A cynical answer but a correct one.

But will the Foundation commit to maintaining this extension in the long term?

This is a discussion for T110170: Goal: Deploy Newsletter extension in Wikimedia. See you there. :)

PS: I'm well aware of of the problem of software maintenance. Then again, if Wikimedia would have deployed only software written by people guaranteed to stay around in the long term, we would have never got MediaWiki and friends. I still think this feature is needed and will be welcome by many authors of current and future newsletters.

But will the Foundation commit to maintaining this extension in the long term?

WMF and volunteer developers do critical maintenance on all extensions deployed to Wikimedia. Whether or not there will be long term resources dedicated to improving the extension depends on a lot of factors which are anyone's guess, but if it is deployed, it will at least be kept in working order.

In this particular case, I believe yes, because several Foundation-led efforts---the Research Newsletter and Tech/News---will come to rely on it. A cynical answer but a correct one.

This is really an important part of developing software. If newsletters, like mine, are going to use an extension, it is important that continuity is arranged.
And again, general, I see too little commitment in the Wikimedia Foundation to secure the continuity.

if Wikimedia would have deployed only software written by people guaranteed to stay around in the long term

Sorry, but this is not the essence. It is not about individual people. It can be various people. The essence is that WMF gives a guarantee.

I still think this feature is needed and will be welcome by many authors of current and future newsletters.

I think not, the number one overall complaint from the community what I see (beyond the irritations of changes and worse styles of implementations) is that the community gets bored that again and again and again software is failing and no longer repaired, while the community makes active use of it. Sure there will be lots of people who have not the previous experience of failing software due lack of maintenance, and like the extension, but that is overall only a short term situation of continuity is not guaranteed.

@Romaine, what @Bawolff said.

T110170: Goal: Deploy Newsletter extension in Wikimedia has a long and complex review process ahead, designed to test the appropriateness and robustness of this piece of software and their maintainers.

Even if one day this extension is implemented in Wikimedia, newsletter owners will not be forced to use it. If you want to keep your current way of managing your newsletter, just keep it. And in the way it is designed, even if the extension blows up and disappears one day, users of this extension would be able to go back to the current way keeping whatever subscribers they have.

So really, I don't see which harm we are causing by trying to develop and contribute the right thing.

I think we keep too much talking around the core of the problem.

disappears one day, users of this extension would be able to go back to the current way keeping whatever subscribers they have.

You are with this confirming the problem I indicated.
Unless a software development is intended to be temporary, one of the most important parts for end users is continuity. As I said in my initial post about the problems in the process, this is an example of such problem. The continuity as important aspect would have come up if there was a genuine involvement of the stakeholders/end users.

I was concerned about the process, but I am now really surprised. If important factors for end-users are missing in software, the software is incomplete. If I tell this to my community, they find this crazy. Not to mention the waste of resources.

@Romaine, the problem I see is that you leave us no reasonable options following your line of argument. According to your standards, what specific requirements should we handle in this project to guarantee this continuity? A full-time position hired by the Wikimedia Foundation with budget assured for the years to come? And if we don't reach your standards, should we stop this project altogether? This is literally what I understand reading your comments, please correct me if I'm not understanding your recommendations.

As said several times, there is a process to evaluate extensions willing to be deployed in Wikimedia servers (T110170). That process is open for community enquiries and feedback. I will be the first one not pushing for this extension if its development and maintenance plan has open blockers or other flaws. The people that can seriously stop this initiative are the ones that will have to eventually maintain it if the three current contributors involved suddenly disappear from planet Earth. It's free software, all the code and documentation is available, and this is the ultimate guarantee that if there is a serious problem, it can be solved by someone with the skills. This is how the actual economy of open source software works, at Wikimedia and mostly every project maintaining a large codebase.

If important factors for end-users are missing in software, the software is incomplete.

Please, file tasks for any feature you are missing.

If you try to say that there is no way to fix the issues I bring up in this particular software development, yes I am aware of that. I try to give feedback not just for the moment, but also for future developments.

please correct me if I'm not understanding your recommendations

You are not understanding my recommendations.

And I finish reacting here, I have made my points clear. Other people seem to understand them, and being ridiculed is not something I would like to continue.

Hello !
Its long I have been active in this group. Can someone help me up ? I have
a page called CA. Uttam Agrawal. And its been deleted by the community. I
worked hard on it and all my coded stuff are gone. Help me up !! I need it
urgent.

Resheil Agarwal,
Founder,
Webportal.in

In T76199#2325761, @ResheilA wrote:

Hello !
Its long I have been active in this group. Can someone help me up ? I have
a page called CA. Uttam Agrawal. And its been deleted by the community. I
worked hard on it and all my coded stuff are gone. Help me up !! I need it
urgent.

Was your page on a wiki? If yes, I think you should contact the people who maintain the wiki in which your page was in.

@ResheilA: Hi! Whatever page called "CA" you refer to, it's unrelated to this software development task about creating a MediaWiki extension called "Newsletter". Please either use https://www.mediawiki.org/wiki/Project:Support_desk for general software problems, or the village pump of your Wikimedia site instead. Thanks.