XSF Communications Team - 2022-10-15


  1. emus

    Hey everyone, first of all thanks for doing and continuing the translations. Yes, I know the problem, but Github is not my choice and I dont see its being chnage anytime soon. So that downside is what will last for the moment. What I could definitely agree to is using .md files prepared for upload. Or if you find a way to push it from some remote platform repo as pep. mentioned In general I would love to see the newsletter translations on xmpp.org directly. Translations are really important as I just saw during my vacations. Many people are not as good in English as we might believe

  2. emus

    Does that sound meaningful?

  3. emus

    neox, MSavoritias (fae,ve):

  4. pep.

    emus, technically, you, or someone else having rights on github would pull, instead of them pushing (since they don't have an account/don't use it)

  5. MSavoritias (fae,ve)

    That was my thought too. But git being the complicated thing that it is i dont want people to learn do it jlst for this. If they dont already know it that is

  6. emus

    Pull it from a codeberg repo?

  7. pep.

    emus, from any repo

  8. pep.

    People would tell "you" where their translations are available

  9. pep.

    I'm curious to know if a platform allows this directly

  10. gooya

    Why not selfhost a gitea instance?

  11. pep.

    Because it's not necessary for this to work

  12. MSavoritias (fae,ve)

    Wouldnt creating a fork also work in another platform?

  13. MSavoritias (fae,ve)

    Or is that what we were talking about 😅

  14. pep.

    I'm trying to write a small thing to show what I'm talking about.

  15. MSavoritias (fae,ve)

    👍 I was going to say blabber has a similar setup of what i am thinking.

  16. pep.

    https://bpa.st/raw/K4VA This still assumes that pulling from github is fine. If that's also an issue, we'd need a mirror somewhere else indeed

  17. pep.

    At least there's no need for an account here

  18. pep.

    thoughts?

  19. MSavoritias (fae,ve)

    I think it can be made easier

  20. MSavoritias (fae,ve)

    Look at this: https://codeberg.org/kriztan/blabber.im In the sense of, if we make a repo mirror like blabber ^ Then we dont need to clone from tne github xmpp.org

  21. MSavoritias (fae,ve)

    But i agree with the idea

  22. MSavoritias (fae,ve)

    I am trying to see how its set up in codeberg now

  23. pep.

    Someone still needs to pull to GH no ?

  24. MSavoritias (fae,ve)

    Ah yeah. So basically i imagine the steps will be: Translator: Pull from translations repo and push there. Website team: Pull the translations repo and merge it

  25. pep.

    Just one other remote then

  26. MSavoritias (fae,ve)

    Yeah. My thinking was tnat we can put all the translations in one place instead of multiple. And the website team has to pull only from there

  27. MSavoritias (fae,ve)

    So codeberg doesnt support it UI wise so its gonna have to be manually

  28. MSavoritias (fae,ve)

    So I made a repo in sr.ht and codeberg both can work. What is the consensus of the approach?

  29. pep.

    Didn't support what? Mirroring?

  30. pep.

    Doesn't support what? Mirroring?

  31. MSavoritias (fae,ve)

    Yeah. Through the UI. I can setup the github repo to point to the sr.ht/codeberg repo and have it as a mirror through the terminal.

  32. emus

    wurstsalat: what do you think?

  33. emus

    I wonder how much additional wir might be

  34. pep.

    It's not integrated into GH, you can't just click a button, so it might be a bit more work if you'r enot used to handling git directly

  35. wurstsalat

    > wurstsalat: what do you think? I don't care. It does not matter which way you choose. All these steps create extra work. Send it via mail, put it in some online pad, push it to some repo, ..

  36. emus

    yeah, but if its intitive

  37. emus

    I wonder if the teams could find someone to just push it to Github

  38. pep.

    https://docs.gitea.io/en-us/repo-mirror/#pushing-to-a-remote-repository codeberg should support this right?

  39. pep.

    I wonder if we can trick it to think github is the mirror

  40. pep.

    And if it fails if the thing differs

  41. MSavoritias (fae,ve)

    There is automated pushing that can be done too

  42. pep.

    Well it's just below in the doc

  43. MSavoritias (fae,ve)

    The reason i didnt propose is because it needs a token and somebody that has commit access to xsf to get it

  44. pep.

    "NOTE: This will force push to the remote repository. This will overwrite any changes in the remote repository!" ah, this is a no-go

  45. MSavoritias (fae,ve)

    The reason i didnt propose is because it needs a token and somebody that has commit access to xmpp.org to get it

  46. MSavoritias (fae,ve)

    Ah

  47. pep.

    We'd have to be careful when pushing, and I don't want to promise no-one is ever gonna make a mistake :P

  48. pep.

    (Even though technically it's not an issue as we can force push the original thing, but..)

  49. MSavoritias (fae,ve)

    Isnt that more risky than just mirroring? I can take care of the mirroring because i am ok with terminal and every other translator can just use the ui

  50. MSavoritias (fae,ve)

    With sr.ht it would just be an email. No idea about codeberg

  51. pep.

    codeberg is gitea

  52. pep.

    Pulling on $otherrepo isn't gonna automate the pushing, you'll need somebody to pull from gh yeah. But gathering everything is one place (for those who don't want to push to gh) would make it less annoying for commteam (than more remotes)

  53. singpolyma

    Mirror doesn't get you anything in this case. Pulling/merging from any remote is the same one command for the maintainer, that's the beauty of git

  54. singpolyma

    You lose the one click merge in GitHub, but that's always optional anyway and isn't really safe in code repos anyway (though I understand most of those concerns don't apply here)

  55. pep.

    singpolyma, it gets you that the amount of remotes is reduced, but yeah it's not mandatory I guess

  56. pep.

    (if people coordinate to push to the same place)

  57. singpolyma

    When someone sends a path they can run git request-pull and send you the output so you can't just cut-paste the command to merge it

  58. singpolyma

    When someone sends a patch they can run git request-pull and send you the output so you can't just cut-paste the command to merge it

  59. singpolyma

    When someone sends a patch they can run git request-pull and send you the output so you can just cut-paste the command to merge it

  60. singpolyma

    Or tell you the url some other way of course

  61. emus

    Maybe the easiest thing would be: - prepare an .md file - Send it to me or let see if there even is a volunteer to organise the file migration - place the file

  62. singpolyma

    Sure, if it's just a single new file diffs/commits/merges might be overkill if people aren't used to git anyway

  63. emus

    We have two issues in general I believe: - keep the barrier low (I think we fixed it mostly so far) - keep amount of work low or find more contributors for specific general tasks When it comes to the second point, the setup currently is rather thin. So each new thng should be checked against this. I could believe to also have an official pad, where everyone can participate to translate for a specific language. then push it in the end or ping me. We might just agree on the webtool. What do you think?

  64. MSavoritias (fae,ve)

    Yeah i think it depends how much its going to be used. If we have only 1-2 translations that will not be in github its not worth it to have a whole repo. Might as well send markdown files in this room. If its more interested parties then it starts to make sense imo

  65. TheCoffeMaker

    emus: Hi ... +1 to having a pad by language and +1 to notify u or sending the PR when it's done ... Because github is a barrier for people that want to contribute but dont want to be part of github

  66. MSavoritias (fae,ve)

    This sounds good too ^

  67. neox

    For the french translation, we already have our own team procedure, based on the LinuxFR redaction platform. So using a pad for french would just make contributions erratic since I would have two locations to check for contributions...

  68. neox

    I prefer to send a fully prepared md file here

  69. emus

    Ok, but can you have a description how to join your team procedure? Maybe we can have a wikipage describing where to and how to participate?

  70. emus

    wurstsalat: what do you think about the pads?

  71. emus

    same as before?

  72. wurstsalat

    emus, adding a .md file by hand is fine by me

  73. emus

    Maybe we start pads, communicate this, but translators who want it on xmpp.org would need to send a .md in the end?

  74. MSavoritias (fae,ve)

    Why not just send the .md directly? Would that be a problem?

  75. MSavoritias (fae,ve)

    I am thinking it would complicate thing fith pads and .md plus the github

  76. wurstsalat

    emus, we should let translators decide on how they want to contribute this. Github is highly preferred, since it does not create extra work for Comm-Team. Sending a .md file is ok here, if registering with Github is such a hurdle.

  77. emus

    Yes, but my idea is also to unify, the translation process a bit (if everyone agrees). So we can exchange and guide people there and ensure backup and continous publications. So if we have "one" process for translations we can also communicate this by end of the day

  78. MSavoritias (fae,ve)

    The "unified" procedure i see at the moment is: Create a markdown file with your translation, sent it to the Comms room.

  79. MSavoritias (fae,ve)

    I agree that it is a high barrier though for new translators. But I am sure the issue is known also

  80. MSavoritias (fae,ve)

    I agree that it is a high barrier though for new translators. Im not sure how many people are even going to bother. But I am sure the issue is known also

  81. emus

    I would also make the participation ways more transparent

  82. neox

    > Ok, but can you have a description how to join your team procedure? Maybe we can have a wikipage describing where to and how to participate? emus: - neox (myself) translates the whole newsletter as a first pass - neox posts the translation alongside original blocks of text in the redaction platform of LinuxFR website, a well-known place for french free software movement - anybody can contribute then for at least a week to the translation (by correcting, adding, etc) - I review the whole contributions, verifying that it is still with the same spirit as the original, and if needed I let comments to enhance some contributions - When everything's ok, I submit the translation through LinuxFR moderation (where it will be corrected a last time by moderators if needed) and I wait for it to be published, then I send it to news.jabberfr.org - I export the resulting markdown and send it to you

  83. emus

    👍 do you have a xsf wiki account?

  84. neox

    emus: yep

  85. emus

    Would you like to go ahead on and create such a page with this description for the french side? We have a CommTeam page there.

  86. neox

    Ok, will do 👌

  87. emus

    Many thanks