Add sponsor button to github

[yringler]

I really appreciate all the hard work that you put in maintaining and improving your flutter plugins. Things I'm trying to do would be extremely difficult without it. Please consider adding a sponsor button to your repos.

[ryanheise]

Hi @yringler , thank you very much for your kind support! It's something I haven't considered before, but I'll definitely look into it as an additional way to support the project besides PRs and issues/bug reports.

One way that GitHub considers who to accept into the sponsor beta programme is whether they have been recommended by the community, so if you'd like to recommend me for the sponsor programme, the following form appears to be the place to suggest my username:

https://github.blog/2019-06-12-faq-with-the-github-sponsors-team/#how-does-the-waitlist-work

[yringler]

Done :+1:

[shimorojune]

Done

[yringler]

@ryanheise , how's this going?

[snaeji]

Done!

[ryanheise]

@yringler , @snaeji , @RohitRajP , thank you all so much again for prompting me to add a sponsor button. I am now in the process of signing up and it is expected to take between 1 to 2 weeks. I would love to put donations towards financing for a mac so I can do a better job on the iOS side.

It looks like GitHub uses a tiered approach similar to Patreon where higher tiers can potentially have perks. I don't want to artificially make up perks that aren't actually wanted, but I'll happily add perks if they are suggested, and until then I'll plan to start with a single vanilla tier.

[duncan-iaria]

This looks to be live now! Let's get this man a macOS device!!!

[yringler]

Nice!

[yringler]

@ryanheise , you can have a sponsor button showing on all repos with a .github repository. Here documents the "global" github config files for an account, and here is all about FUNDING.yml.

Here is an example.

[yringler]

@ryanheise , can you add some higher tiers? Or a different payment method? You're work is critical to mine, and I really appreciate it. Perhaps Liberapay, which is recommended by remmina.

In some circles it's customary to make donations in multiples of 18, the numerical value of the Hebrew word for "life".

[ryanheise]

A big thank you @duncan-iaria and @yringler ! I just woke up this morning to see your sponsorship.

@yringler , I was going for a "binary" theme with powers of 2, so the next tiers would have been $8 and $16 but for the time being I've run out of clever puns beyond the second power ;-) I will think on that.

The next step is certainly to complete the GitHub sponsor button setup via FUNDING.yml .

Adding multiple platforms sounds interesting although I will need to check the tax rules for each country (Librepay is in France, GitHub is in the U.S. and I'm in Australia, so I need to fill in different tax forms depending on what tax treaty, if any, Australia has with that country, etc. and I also need to consult a tax accountant who understands these things to ensure I'm doing everything correctly).

[yringler]

@ryanheise , there isn't a chat on github (although I think there is such a thing in beta), and I don't want to open a new issue for this, but wanted to let you know that I nominated just_audio and audio_service for flutter favorite. Chris Sells got back to my email, that the committee will take a look. That would be cool!

[ryanheise]

Thanks for the nomination!

In my mind, audio_service has always been a pre 1.0 release (in the semantic versioning sense), for the reason that the start/stop API hasn't reached its "ultimate form" yet ;-) But of course that is not one of their metrics and Flutter Favourites has accepted pre-1.0 in the past.

[yringler]

@ryanheise, did you see the new github discussions? I enabled it on a repo of mine to check it out, it seems quite useful. Currently in beta.

[ryanheise]

Hmm... It's interesting to think about. Here are some of my initial thoughts about its different uses:

• Q&A: I think StackOverflow is probably better. It has a good system for filtering question quality and eliminating duplicate questions. Being a separate website may also be a healthy way to prevent a single company from handling everything ;-)
• Ideas: I like ideas discussions, although our current system of creating a Feature Request issue seems to suffice, and in some ways is better: It's all under the same issues page so I can easily manage what issues I'm currently working on through the label filtering system.
• General: It's true I don't have a spot for this yet but I would prefer to have specific categories anyway.
• Show & Tell: I like this one. It would be great to hear what people are doing with audio_service.

It may be that bringing Q&A over to here from StackOverflow will help to build critical mass and thereby make it easier for the Show & Tell thread to gain traction (as opposed to if Show & Tell were the only discussion category there). It also may lower the resistance of people to follow the link to an external website for asking questions, and in effect, could lower the burden to close invalid issues. If I use discussions, it would make sense to use the Q&A and Show & Tell categories.

The only downside then is that it would be bad for StackOverflow if everybody follows suit and moves their Q&A away from a well-established site and quality site. I might wait a bit to see how others may (or may not) choose to adopt it.

[ryanheise]

https://news.ycombinator.com/item?id=22388639 touches on some of the thoughts that have been going through my head.

[ryanheise]

just_audio was just accepted by the committee as a Flutter Favorite! Thanks to @yringler for nominating the project, and others who also nominated the project, It was quite an intense period for me trying to improve the quality (and I ended up spending most of that time focusing on just_audio since it was closer to meeting the required standards), but it's great to finally have all of that hard work paid off. It's also completely understandable that they only picked one of the two plugins, but I think that's fine since the just_audio README contains a prominent link to the audio_service project.

I have noticed just_audio on an upwards trajectory for a while where it's number of likes was projected to overtake audio_service. And just yesterday, that crossover point happened. Another positive thing that happened for the project is that someone created a just-audio tag on StackOverflow so it is much easier to now link people to relevant SO questions, and for me to subscribe to just_audio questions. It would be great to have a similar tag for audio_service but only someone with a very high reputation can create tags.

I may be celebrating just_audio too much on an audio_service issue, but I'm getting back into the swing of things with audio_service, and should have a couple more commits out today.

[yringler]

That's fantastic news! Now let's get a flutter favorite badge on the just_audio readme, stat!

[duncan-iaria]

That really is fantastic! Congrats @ryanheise!

[ryanheise]

Thanks @yringler and @duncan-iaria !

Regarding the badge, I've done some research and it seems that actually only 10 out of 37 Flutter Favorites have decided to add the badge to their README:

• https://pub.dev/packages/provider
• https://pub.dev/packages/flutter_bloc
• https://pub.dev/packages/bloc
• https://pub.dev/packages/flutter_slidable
• https://pub.dev/packages/animated_text_kit
• https://pub.dev/packages/mobx
• https://pub.dev/packages/flutter_mobx
• https://pub.dev/packages/convex_bottom_bar
• https://pub.dev/packages/sign_in_with_apple
• https://pub.dev/packages/mobx_codegen

After all, pub.dev automatically inserts the badge into the page header, too. So I guess one the one hand it might be redundant, but on the other hand it could help make it more visible.

I'm the sort of person who suffers from "paralysis from anaysis" so for the time being, I'll probably leave it as is, but if you think it would be a good idea to embed it too, would you be able to suggest which of the above embed layouts you prefer?

[stonega]

Congratulations! @ryanheise

[ryanheise]

Thanks, @stonega !

It's been really amazing having you all along on the ride, supporting and contributing to the project.

[ryanheise]

[pureimpro]

You really deserve it ! Congrats 🤗

[ryanheise]

Thanks, @pureimpro !

[yringler]

I really like how it's done for the bloc packages Where the favorites logo is right aligned, the package logo is center aligned, and all the badges are organized neatly below it. IMO it would be great to have the badge like that, but only as part of a redesign of that top portion of the README. Just dumping in the logo looks... amateur

Any designers here who could volunteer to make a logo?

[ryanheise]

I was actually thinking it could be good to have a logo or brand to stick on any audio plugin that is designed to cooperate with other audio plugins. In particular, there are some singleton platform resources made available to an app which, if one plugin takes ownership of, will interfere with the operation of other audio plugins that attempt to do the same. Examples include:

• Audio focus (via AVAudioSession on iOS and AudioManager on Android)
• iOS audio session category and options
• Android media session
• Android media browser service
• Android media button receiver

Rather than build these capabilities into every single audio plugin so that every audio plugin conflicts with all others, what we need to promote is reusable packages that can be mixed and matched together and which avoid overlapping responsibilities.

As an example of bad things that can happen, audio recorder plugins tend to bake in the setting of the AVAudioSession category to "play and record" or "record", while some audio players may hard code it to "playback". If an app loads both plugins, whichever one loads second will override the settings of the first and potentially break the app (see audio_session for a solution to this problem). So to have an ecosystem where audio plugins can work together, there needs to be some awareness of which responsibilities could overlap with other plugins and how to avoid such conflicts.

Such a project probably deserves its own GitHub site with its own guidelines.

At the same time, many users of course are looking for a convenient plugin that sets up everything for their particular use case, and the most common use case is an audio player that contains a service for background audio capabilities and also manages audio focus for you. I think there needs to be a way to provide this convenience but without requiring all of these dependencies to be inseparable. I was recently experimenting with leveraging the federated plugin architecture to achieve this (https://github.com/ryanheise/just_audio/issues/312).

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs, or use StackOverflow if you need help with audio_service.