Create Mailchimp module

[PatrickHeneise]

Have new labels 'job offers' and 'must read' with jobs and coding resources that can be send together with the mailing.

Then there should be a newsletter/email about a week before the event (triggered manually or automatically, no idea) with:

• general event info
• talks
• other cool stuff in the city
• resources (links, articles)
• jobs
• sponsor info etc.

[iancrowther]

see https://github.com/barcelona-js/gitup/issues/17

[PatrickHeneise]

Wrote a mass mailer already here: https://github.com/blendedio/mailer, using the node-mailer module which supports Mandrill, Sendgrid or whatever is preferred.

[iancrowther]

ok cool - so this is a post hackday task for when we create the LNUG production build

[PatrickHeneise]

Leave it open ... it remains an issue ;)

[iancrowther]

oki doki

[iancrowther]

@ifraixedes

[PatrickHeneise]

I guess it should be the mailchimp API after all, since all email addresses are stored there and we have templates there.

[ifraixedes]

Yesterday, I was pairing and I could read all the things were happening. I've just seen that you moved Gitup project to the new GitHub organisation called GitEvents, main project on https://github.com/GitEvents/gitevents.

I've also seen that the project that @gajjargaurav and I created in my github has been forked by GitEvents, which is better.

If I don't make a wrong assumption, the idea is work in our forks and send PRs back to the project.

I'm writing the README which define specifications and others, but it will contain the idea that we were discussing however I'm writing that we encourage to have an open discussion to agree what to implement. I'll send a PR during to day with that README and I will open an issue for each part that we encourage to the community to discuss before lock in and do the first implementation.

@PatrickHeneise implement an API for a specific provider (mailchimp) and its relation (template engine) is easier and simple, but I though, maybe wrongly, that we don't want to lock in into a provider or template, we want architectures more pluggable for each community could use whatever is convenient for them, e.g. @barcelona-js uses meetup for some reasons however @lnug doesn't.

I know that the problem to be generic is we lose specific features of the provider, that it's the challenge, try to be generic however don't lose too many valuable features supported by different providers; hence my idea is to implement a core which is pluggable but bearing in mind simplicity in terms of using the module as the APIs for different kind of plugins that we want to expose.

Another reason that I think that we cannot lock in into a email provider is because the organisation may prefer to use a local email provider to avoid email be capture by email filters (e.g. local provider send emails using IPs in the audience's region), contributors are more comfortable to use a specific template engine because they are used to working on it or because the mail provider doesn't provide one (e.g. mailgun).

Let you know, that we made some research of the current mailer implementations, as we know nodemailer is a good implementation however in terms of community I understand that we always have to use a mail provider and although it supports providers we wanted something that we can still using valuable providers' features.

On the other hand, if we want to use mailchimp, campaign seems a good solution; we evaluated it, it is pluggable and support maichimp by default, the only inconvenience that personally I don't like is it has options that are bound to the template (e.g. teaser) and I was not clear what it meant until I took a look to the code and saw that it is a variable in the example template, then if you don't know in advance and build your template without it, you may think that teaser option still working but it isn't, but maybe my interpretation is wrong as I'm not an expert in the mailing scope.

Anyway, as I've commented I will send a PR today with that README.

Peace out.

[PatrickHeneise]

@ifraixedes The whole plugin architecture allows to use whatever you want. It's not that I like meetup, in fact I really really don't. But attendees want it (bcnjs without meetup: 30 people, with meetup: 110). That's why I want to use GitEvents; managing external sources through GitHub, no matter what you're using.

I'd love to have the mail module independent as well. But I realised if we do it with an SMTP mailer (mailgun, mandrill, whatever), we need to store the email addresses somewhere. Something I don't want to do, for security reasons. In Mailchimp you have the signup forms, unsubscribe stuff and everything else which makes it really convenient. Put in some talks, jobs, news from the GitHub issues and send mail, completely automatic, that'd be excellent in our case.

[ifraixedes]

@PatrickHeneise I know why bcnjs is using meetup and your preferences, I think the same than you about meetup, but as a community we have to leave aside our personal preferences and for that reason bcnjs returned back to meetup.

About the mailer, I've thought about those issues (e.g. the addresses list), so I will add them to the README as part of the specification and although as a first thought is difficult to bear in mind everything we could start to think about it and start the first implementation and improve it as any software development cycle. Thanks for your reply, so it helps to remind me to add them in the general specification.

Thanks to be clear

[iancrowther]

can we get the maillist from mailchimp via api? that way they keep the unsubscribe functionality

[ifraixedes]

For sure that we have to use the features that the majority of the providers offer, for that reason the mailer should be modular an pluggable without losing this basic and as important features.

[iancrowther]

@PatrickHeneise is this going into it own repo? or being depricated

[iancrowther]

pls could you add a reason for closing :-)

[PatrickHeneise]

cleanup - it's too old and irrelevant. Once it's added on the roadmap, we can define a proper issue for it.