SPI-updates bot to @ owners on Twitter/Mastodon

[MahdiBM]

I feel like it's a missed opportunity that SPI-updates accounts on Twitter/Mastodon don't @ the owners.
It would be both more discoverability for the owners, and also they might retweet SPI-update's post once in a while.

You could get the handles from the owner's profile (assuming Github allows that through their API, or I guess web-scrapping is also an option)

There might also be more things to consider, such as:

• A configuration option to disable these @ s if owners don't like it.
  I don't think this will be a problem, considering the deterministic behavior of the SPI bot, but won't hurt I guess.
• A configuration option to change the account that is mentioned.
• Generally there is a potential for abuse in this, which might happen rarely.
  Someone could put someone else's @ in their profile so the SPI bot @ s the wrong person.
  You might want to passive to roll out this feature just to make sure nothing goes wrong. For example just do the @ for repositories with 10/20+ stars. That might make sure the abuse is adequately hard to not be a problem.
  Again, I don't think this will happen often. Not sure if it's worth considering for now.

[finestructure]

It would indeed be nice to be able to reference authors. In addition to your list of things to consider: Some packages release frequently and if we opt all packages into this we might be tagging folks too often.

Some ways we could mitigate this:

• make social media accounts an option in .spi.yml and only tag authors when they do so (opt-in vs opt-out, and also way easier to implement)
• only tag package adds, or only package adds and major releases (or minor releases, i.e. skip patch releases)

[heckj]

I'd encourage an opt-in from owners - primarily because I've submitted packages on other's behalf (to expand the index and get them visible more for myself and someone else I'm telling about that package) - so at least in some cases, the "owner" never signed up for the additional notifications.

[daveverwer]

I think asking users to actually ask for mentions will make the feature too unused

You’re right that it would be challenging to get people to opt-in, but as mentioned by @finestructure and @heckj, I agree that it must be opt-in. Even if we were able to get Twitter/Mastodon usernames in an automated way, pinging people on package releases is the wrong side of the line towards spam for me.

If we did it, we could add information to our “Add a package” and “Information for package maintainers” pages showing how to opt in. That does work well for getting people to add the badges.

It’s a good idea, and if people did opt in it would be a potential source of growth as it’s likely those people would retweet/repost their package releases, driving followers/traffic.

If it had to be opt-in, is it something you’d be interested in implementing?

[MahdiBM]

If it had to be opt-in, is it something you’d be interested in implementing?

Yes for sure. I don't mind the opt-in vs opt-out myself, after all it won't be more than a line or two in the SPI configuration file. I was just trying to put myself in your shoes and see what could possibly be the better way of implementing it for the bot.

I think the whole discussion of making it opt-in vs opt-out is subjective so we don't really need to agree on anything anyway since we (or at least me) don't have some direct statistical data on the matter. I guess the opt-in version will also look more "professional".

Again, I'm not exactly sure which one would be better, it's just in my head the opt-out version plays nicer than the opt-in version. I could very well be wrong 😅

[MahdiBM]

Some awareness around the feature could solve most problems like we all mentioned, both for opt-in and opt-out.
You can just make sure the feature is mentioned in a proper place and with a proper explanation so most people can see it and enable it if they want.

[finestructure]

I think a good place is to start with an opt-in via the .spi.yml, because it's also way easier to implement. We can then explore ways to make opt-in easier.

For example, I could envision we add a way to generate a PR against a package repo with a pre-generated .spi.yml file.

It could be a template that does this opt-in but also adds the basic fields for doc generation.