search

laravel-notification-channels / channels

Submit suggestions & pull requests here for new notification channels
https://laravel-notification-channels.com/
200 stars 186 forks source link

New Channel Proposals #6

Closed themsaid closed 4 years ago

themsaid commented 8 years ago

Suggesting a new channel

Have a suggestion or working on a new channel? Please create a new issue for that service.

I'm working on a new channel

Please create an issue for it if it does not already exist, then PR you code for review.

This thread is too long, and it will be easier to keep track with suggestions/wip channels split into different issues.

FAQ: http://laravel-notification-channels.com/

christophrumpel commented 8 years ago

So is there a list of what is left ?=)

irazasyed commented 8 years ago

How about a Skype and Kik channels?

They both support bots too.

themsaid commented 8 years ago

GitHub Issues maybe?

irazasyed commented 8 years ago

Twitter would be so good too!

DM or Tweet. To notify personally or send public notifications to all followers.

mpociot commented 8 years ago

So many awesome ideas! :heart:

christophrumpel commented 8 years ago

Do you use any package boilerplate code? I would like to checkout Twitter

themsaid commented 8 years ago

@christophrumpel https://github.com/laravel-notification-channels/skeleton

Here you go :)

freekmurze commented 8 years ago

@christophrumpel Yea, we have a skeleton to help you get started: https://github.com/laravel-notification-channels/skeleton

themsaid commented 8 years ago

@freekmurze haha, second time in a single day.

freekmurze commented 8 years ago

Yup, haha. And for the second time, I'm just a few seconds too late 😄

christophrumpel commented 8 years ago

Haha sry, of course. Benn there already! Guess this day was too long for me already =) thx!

arcdigital commented 8 years ago

@themsaid Can you create a repo for AWS SNS?

arcdigital commented 8 years ago

@themsaid Also a discord repo?

themsaid commented 8 years ago

@arcdigital created one for AWS SNS: https://github.com/laravel-notification-channels/aws-sns :)

themsaid commented 8 years ago

Also another for discord: https://github.com/laravel-notification-channels/discord

codyphobe commented 8 years ago

Discord channel is nearly done, I just need to write an artisan command to streamline the bot setup since they have an annoying and undocumented requirement.

christophrumpel commented 8 years ago

I've started with Twitter. Hope I can push something tomorrow.

themsaid commented 8 years ago

A twitter channel was created for you 🎩

iWader commented 8 years ago

Pubnub channel is ready to push #11 just the tests to write. If anyone has pointers that would be great, relatively new to testing.

JayBizzle commented 8 years ago

I've got a proof of concept Ionic Push Channel up and running, ready and waiting for it's own little repo 👍

themsaid commented 8 years ago

https://github.com/laravel-notification-channels/pubnub https://github.com/laravel-notification-channels/ionic-push-notifications

@iWader & @JayBizzle here you go :)

JayBizzle commented 8 years ago

Thanks, just need to tidy up my code then will push ASAP

jhaoda commented 8 years ago

12 is ready.

irazasyed commented 8 years ago

Guys,

Please take a look at #15 - A proposal to add authors to the organization. Suggestions/Thoughts are welcome!

Thanks!

javidsapand commented 8 years ago

@themsaid Will work on Ably. Put my name on the list.

mattheworiordan commented 8 years ago

@javidsapand if you need any help with Ably, please shout, happy to help wherever you would like assistance.

barryvdh commented 8 years ago

We (Fruitcake) are going to create a plain APN (Apple Push) en GCM (Android Push), without 3rd party. Is it okay if I just use my own organisation and still be listed? Like to be in my own control ;)

Edit; skeletons here: https://github.com/fruitcake/laravel-gcm-notification-channel and https://github.com/fruitcake/laravel-apn-notification-channel

freekmurze commented 8 years ago

Hi Barry,

thanks for contacting us.

we’ve discussed your question and we think it’s best that all the notifications packages that are associated with our organisation are developed under our organisation. We do like that every package works more or less the same, so our users can easily use any of the packages.

Should we setup two repo's for you? Of course we’ll give you write access to your own repo. While we don’t foresee any troubles in the future, you always have the option to publish a fork of the code under your own organisation.

barryvdh commented 8 years ago

Hey, no thanks, I'll just keep them under my own organization. I understand your concerns. Perhaps you could consider adding a 'unofficial' or external list of notification channels, to prevent people from doing the same work, but still making a clear distinctions between your own channels and the rest. (of course I will still follow the notification guidelines and common best practices, but like you be in charge of the things I create ;))

freekmurze commented 8 years ago

Maybe we could do that, ping us when you're ready with your packages.

sid-bg commented 8 years ago

Hi @barryvdh, love your work but I think you're being a tad selfish in this situation.

In my opinion, all channels not native to the framework are 'unofficial'. So there's no point in listing 'unofficial' channels. You want to retain control of your channel but want to be promoted under another organization's umbrella.

You should be honest and clarify that you want the channels to be under your brand. Because there's no loss of control by having a repo with write access here.

barryvdh commented 8 years ago

You think I'm selfish because I'm publishing open source channels for free, instead of keeping it private?

  1. Yes, because I spend my companies time and resources on this (we we're using GCM/APN already internally, but I asked the developers to move it to a package for Laravel notifications), I do like to get recognition. But I don't think there is anything wrong with that.
  2. Write access !== in control. If I publish the package under this organisation, it will still have full access by the org. admins. And they could strip away my write access anytime (not that I don't trust @freekmurze or @themsaid !). Also, if we have a disagreement of how to handle something, I would like to be the one that makes that call, because the packages will be used in our production sites..

And honestly, it's nice that everything is neatly organised, but with Composer/packagist, there isn't an explicit need to put everything under 1 big umbrella. It's fine if you want to, but it doesn't change the way anything works. Laravel has contracts for notifications, so as long as you follow that, I don't see a problem. And I'm currently maintaining Omnipay, which also has everything in 1 org, but this makes it very unclear who is actually responsible (if any), because the admins don't have knowledge from all packages. That is why we're actually pushing people to create a repo under their own org, instead of adding them to ours..

sid-bg commented 8 years ago

Sorry, I didn't say you're selfish for doing open source. I said you're selfish for wanting your packages promoted by another organization. This is opening a Pandora's box where everyone wants to do things their own way and be listed here.

Just my opinion. I'm not the one in charge here.

mpociot commented 8 years ago

Just to clear things up:

Please leave this kind of drama out of here. If Barry doesn't want to publish his packages under this organization that is totally fine and I don't agree with you that he is selfish about this.

His package, his company, his decisions. That's it.

If I was developing a notification package that is essential for my company I would probably release it on my own too, so that I'm in charge of things.

Case closed ;)

sid-bg commented 8 years ago

No drama. Just don't list them here. That's all I said. Otherwise you'll have to come up with rules and quality control for all external packages that want to be listed.

Last Post.

irazasyed commented 8 years ago

Well, the so-called "drama" just opened up some valid points to consider and some concerns.

Quoting @freekmurze "you always have the option to publish a fork of the code under your own organisation."

  • Why exactly is the author of the package being asked to publish their fork? As the owner of the project, You decide what happens with the package (Or did we just give up the ownership and work to the organization? I thought the authors = owners? No?). It should've been the other way around, and you'd be maintaining a fork just to support the existing users after transferring the original repo's ownership (Though a link back would rather make more sense than maintaining a fork, less of a hassle). Asking the author to fork and publish is pointless when you know that the users are not gonna move, nor you're gonna get any link back (assumption). It's simply like giving up your work and maintaining a fork that you know no one is gonna use it because the current user base is already grown and used to using the project from the org. So having a fork itself is of no use. (Don't get into the whole OSS/license matter, that's not what this is about).
  • The so-called access you give to the authors TBH are not full access and is more of an employer-employee type of access where you've assigned certain tasks to the developer (package author) to do it, and that's it. The author has no rights to select the collaborators, add/remove them, change settings, maintain their repo, etc. It's nothing but merely push rights which are still very restrictive and that's quite annoying, I found that when I got the access and wasn't able to change any settings -- It did bother me, but I didn't think it would matter until a few things happened and now this so-called drama.
  • I noticed some of the PRs getting merged automatically without author's review/approval. Not that the accepted PRs have a problem (I appreciate one of you taking out time to review the PR, It does help maintain the package ofc) but the concern is on more of the higher side of the project where there's a chance of major changes happening on the package without the author's consent or awareness (Or Did we lose that right automatically the moment we opt to add the package into this organization?). Again, The already merged PRs were absolutely fine with me but some level of consultation with the author would've been much better unless the author has explicitly given his consent to take any decision with regards to their package to you (Again, Did we give that away already? Perhaps it should've been clearer and or listed somewhere).
  • As far as the "essential to company" point is concerned, I don't think any package that has been created here are not "essential" to the authors/to their organizations in one or the other way. The ones I created (telegram & facebook) are essential packages for my company too. Because it's an extraction of my widely used telegram-bot-sdk (A piece of this SDK rewritten to fit purpose) which we use it to build bots for our internal use as well as for our clients. The only reason I added the package here was that I thought the listing isn't possible and wanted to let some part of our work out here promoted as well and be useful for others. But looking at the level of access we've been given (restricted) and that, we're not going to be in full charge as later there's a high chance of us being removed for whatever reasons and are left with nothing and simply asked to fork and publish a copy? (Not that I'm saying any of the org. creators would do, but that's a possibility I foresee where the access is restrictive and the whole fork it and publish a copy idea is being suggested). So, Now that the listing of the package is possible, I'd prefer to get my packages listed as well than having my packages under this organization (Glad this discussion happened at an early stage and @barryvdh brought up the topic, good timing!).
  • How about some more transparency? Have all the terms and rights well written and listed on your site. So a new author that wants to join the organization - Reads & understands it before joining? Or as an alternative, just request for listing their package instead (Should they prefer)? Things like:
  • Who owns the work
  • What level of access is being given
  • What happens to the package, if the author decides to abandon or quit
  • What happens if the author decides to transfer the package and whether they can even do that or not
  • What rights are being taken away from the author automatically
  • What are their rights as an author
  • Who decides who can be part of the package as a collaborator
  • Things we should be knowing
  • What are the rules
  • Benefits
  • Who is in charge
  • What are the restrictions, dos/don'ts, code style, structure, standards, and other things?

Please don't label this as drama or as such but some valid concerns I have now (And probably others too). I'm sure the answers to the above points would clarify everyone and give a better idea of what kind of organization this is, where it's headed, what should be expected going forward and our rights.

P.S. Hopefully this doesn't offend anyone (It shouldn't be in fact), These things should be laid out when starting up this kind of project apparently. They are basics! Nonetheless, I respect and like what @freekmurze, @themsaid & @mpociot do and their works/contributions in various ways. 👍

barryvdh commented 8 years ago

I noticed some of the PRs getting merged automatically without author's review/approval

That was exactly what is was afraid of, glad I'm not just being paranoid ;)

The question is also what the goal is of this organisation? Is it: A. Providing a (curated) list of Notification Channels, that follow good standards and are well maintained. or B. Maintain as much Notification Channels as possible, manage contributions and enforce standards on all channels.

If it's A, there is zero benefit on putting everything under the same organisation and you could just as well link to external repo's, after approval.

And if it's B, I hope you're up for a lot of work ;) But it should be clear that by 'handing over' your channel to laravel-notification-channels, you are becoming a contributor with write access, not an 'owner'. (Which is fine, if that is what you want!)

freekmurze commented 8 years ago

Hi,

thank you for those questions. They are all valid. This is the first time that Marcel, Muhammad and I are working with the community in this way, so we are figuring a lot of things out as we go.

Our goal is to create quality notification packages and we focus on the developer happiness that Laravel ingrained us with. There are two parts to that developer happiness. The users of the packages should be able to easily use the code. That's why we like that every package works more or less the same. We don't have very strict rules on that (we're not the FIG 😄 ).

The other side of developer happiness is that you the creators of these packages should be comfortable creating one in this GitHub organisation. That's why we provide a skeleton for you to use so you can get started quickly (this is also helpful in providing a similar usage experience between the the different notification packages). The code review right before the first stable release is also done to enhance the experience for the package user. It's also an excellent learning opportunity for both the reviewer as reviewee.

To answer your questions:

What are the restrictions, dos/don'ts, code style, structure, standards, and other things? --> see CONTRIBUTING.md in every repo. Base rule: provide an excellent experience for package users.

Addendum: we'll refrain from merging PR's in the future, sorry about that.

jhaoda commented 8 years ago

we'll refrain from merging PR's in the future

Good news! And more accurate code reviews, please, because I had to do some fixes after that.

irazasyed commented 8 years ago

@freekmurze Thanks for the answers and taking things sportingly, I appreciate it.

I understand you guys are new to this community type of project and you guys are doing great taking up suggestions, responding, helping, improving and giving your time which would keep the whole community healthy and stable as we grow.

Sounds good about the goal of this project and indeed, It's a good experience for users since all of the packages are quite consistent and the quality is being maintained very well 👍

Who owns the work? --> I'm not a lawyer so can't answer that in a legal sense. Base "rule": it's up to the package author to maintain the repository after it has been released. You'll be given admin rights to your repo. So you are in total control. Only if you ever do something like breaking semver we'll step in. I don't foresee any problems, but if some should arise you're always free to copy over the code to your own repo and abandon the one in our organization.

I'm not a lawyer either but based on the license and generally speaking, It makes sense the author owns their work (Regarding copyrights, unless otherwise, the author has transferred or specifically given some rights). Because what you're providing is a platform to host and promote (Like it was mentioned in Laravel News too). Also, It's best the repo is transferred as GitHub would automatically setup a redirect to the new location as well and a notice can be put up on the site.

What level of access is given --> admin rights

FYI, Admin rights are not being given to anyone! I can confirm this. Because, If we were the admin of the repo, then we would have had access to the settings page where we could change settings, add/remove collaborators, delete repo, transfer repo, and other controls.

Who decides who can be part of the package as a collaborator --> as an admin, package maintainers can choose their own collaborators

When there is no access, we can't really do that unless we request you! Hence, You need to update our rights from the settings page.

Things we should be knowing --> ask us anything, we're very friendly

Good, Highly appreciated.

What are the rules --> you're reading them. I think if we have the same values (creating a good experience for the users) we don't need too many rules. We're basically operating like a Zonda Interop Group 😄 (joke)

Cool 👍

Addendum: we'll refrain from merging PR's in the future, sorry about that.

Thank you!

Those questions were supposed to be put up on the site, perhaps a FAQ for developers. So they can easily know (suggestion!).

So one thing you need to look at right now:

Everything else sounds good. Thanks again for answering all the questions.

themsaid commented 8 years ago

@irazasyed Yes We'll update the access level, just after work hours. Hard to update repos one by one on GitHub while in the middle of coding :D

irazasyed commented 8 years ago

@themsaid That's fine, Nothing urgent :)

mpociot commented 8 years ago

@irazasyed I updated all repositories and set up the right privileges. If I accidently missed someone, please ping me and I'll fix it.

I also added our small set of rules to our website.

irazasyed commented 8 years ago

@mpociot Thanks! 👍

codyphobe commented 8 years ago

@mpociot I'm still not added to the org and have not been given access to the discord repo.

mpociot commented 8 years ago

@cs475x done

irazasyed commented 8 years ago

I created a new one for Hooks app: https://github.com/lukonet/laravel-hooks-notification-channel

You can add it under your external packages section or whatever you're going to call it.

barryvdh commented 8 years ago

Our GCM (Google Cloud Messaging) package is also working now :) https://github.com/fruitcake/laravel-gcm-notification-channel

Do with it as you please ;)

nbourguig commented 8 years ago

Here is a driver for Pivotal Tracker. https://github.com/nikaia/laravel-notifications-pivotaltracker

Code and tests are ready ;-)

etiennemarais commented 8 years ago

Well looking at Trello, I think it might be good to make a Jira/Github issues notifications channels. What are your thoughts?