Magic hook to ping i18n groups of content additions/changes

[snostorm]

I'm thinking of leveraging https://developer.github.com/v3/issues/#create-an-issue to broadcast tasks out to all i18n groups when bigger changes might warrant their attention. Think new content pages, new dictionary definitions needed (with the new homepage coming), etc.

Thoughts?

[snostorm]

cc @iojs/evangelism as you guys may want something to share this for notice of new articles needing translation, etc?

[therebelrobot]

I like this idea, it leverages the current architecture in an easy to manage way. We'd need to set up a bot-user, most likely, for all of the website group, then make an interface for it (which would be simplistic), but then just duplicate the issues/message as an issue in each i18n group? +1

[mikeal]

I'm +1 on the idea but I don't understand how this would work exactly/

[mikeal]

Oh, no, I'm not +1 on creating an issue in every i18n repo :)

Why not just a bot that notices when we add a tag and then comments with @ all the i18n groups ;)

[therebelrobot]

The downside of that is that it's then outside the group's normal issue tracking procedure. We'd get comments in various languages, and if it's an issue in their group, they can attach their own commits to it and separate concerns.

[therebelrobot]

The issue tracker in these i18n groups shouldn't be too big, in theory, so adding one for a new translation wouldn't add too much overhead. Plus they can assign it to whoever they want to handle it.

[Fishrock123]

Maybe something like doing a diff each week and then notifying the translation groups of that would be more helpful.

[mikeal]

The downside of that is that it's then outside the group's normal issue tracking procedure. We'd get comments in various languages

That's not what we've seen so far. Several people from various languages already watch the evangelism repo and wait for the weekly update to finish out. They comment in english and then run it through whatever process they have in their WG to translate it.

The issue tracker in these i18n groups shouldn't be too big, in theory, so adding one for a new translation wouldn't add too much overhead. Plus they can assign it to whoever they want to handle it.

I don't like the impression that it sends. Another WG is assigning them work. The different languages have variations in activity and prioritize work differently, letting them know something new is available to translate and letting them create an issue or a PR or whatever they use to prioritize their work would be better.

Also, several languages aren't active enough to get this done at all which means that their issue tracker will fill up with unattended issues that will scare away new potential contributors.

[therebelrobot]

Those are fair points. The diff idea may be a good idea, create a translation diff issue in iojs/website, then tag all other i18n groups in that?

[snostorm]

I think tagging each group vs opening an issue in each localization has its own pro/cons. It still notifies individual people in a spammy way, just like creating an issue would.

The "new issue" approach might better respect notification options (some people turn off new issue notifications for repos but want other general @ group mentions.)

This also creates a sticky actionable in each WG repo versus a GitHub notification which is easy to lose after clicking skimming past it once. As an example: if somebody joins an i18n group they would still see the history of outstanding work (as issues) versus losing the mentions that predated their involvement. For a slower group winding up, it could be handy to have this to do list.

If we word the Issues the right way they shouldn't sound like strict tasks, more so a gentle heads up that there's some new content around if your group chose to act on it.

Perhaps as a compromise, maybe groups could opt in or out to this system?

[snostorm]

Technical response:

• This could be a bot or simply just triggered from individual users' API credentials. The GitHub API says as long as you have read access to a repo, you should be able to use the API to send new Issues to it. (So no need to create a bot just to be a member of X groups.)
• Given the above, we could use OAuth locally or locally stored API keys (in an io.js script) to trigger the requests as ourselves. That way,
  a) everyone knows who's broadcasting the new Issue (accountability);
  b) If I cared enough to open the new issue, I should care about all of the followup questions/comments that will pop up in the individual repos. This automatically gets me involved.
• I would have all of the i18n group Issues auto tag the centralized Issue as a common point of reference for all groups. Makes it easier to cross link, etc.

[mikeal]

I don't think I understand the arguments about the "spammyness" of notifications vs. new issues. More new notifications will go out if we create an issue in every repo because even the people who were already watching the website repo will get a new notification for the new issue created in the repo they watch.

[mikeal]

Just thought of a much cleaner way. We just write a cron job that adds all the members of the individual i18n groups to iojs/i18n. That way people can opt out by just removing themselves from the metagroup and all we have to do is just @ mention them in any relevant issue :)

[snostorm]

I think I was trying to say both are potentially spammy :)

I wouldn't mind presenting a few options to the i18n groups to get their preferences or chime in? Now, if we only had some sort of simple means to quickly ask them all...? hehe

[stringparser]

Sorry for interrup here, I was just updating the iojs/website/content/es and a simple git log -p <path> really did it for me. Maybe some more additional niceness would help though (like crossing the dates between the content/en and content/es in this case) and give a hint whenever necessary?

[Fishrock123]

Moved to nodejs/nodejs.org#283