XSF Communications Team - 2020-06-29


  1. pep.

    not what I meant. I regularly see report notes articles from goffi in the newsletter. just like that gajim article

  2. emus

    pep.: I think software releases. peetah: I would agree to rename to software releases

  3. emus

    pep.: I think software releases. peetah: I would agree to rename to software news!

  4. wurstsalat

    > The blog post you propose to include is about what has been done since last report about a XMPP related softaware and should be considered as a step leading to the next release of this software I totally agree, and I think renaming the section to # Software News would be best then

  5. wurstsalat

    ## Software releases > ## Software News next question: should the dev post be filed in ### Clients and applications or in a separate ### News section then?

  6. peetah

    the less we split the best it is, so the dev post of a software should go where the release of the same software goes, everything related to the same software being ordered timely

  7. peetah

    the less we split the best it is, so the dev post of a software should go where the release of the same software goes, everything related to the same software being ordered according to its publication date

  8. wurstsalat

    alright!

  9. emus

    yes, lets keep it simple, almost all people won't care. wurstsalat: may you just change the PR accordingly? Then I can merge

  10. wurstsalat

    emus, I already did :)

  11. emus

    wurstsalat: ah yeah, I should check my mails^^

  12. emus

    Github ist down?? 🤔

  13. emus

    ah works again

  14. emus

    wurstsalat, peetah, Martin, vanitasvitae, pep., DebXWoody, Licaon_Kter: So question to the recent contributors, how happy have you been so far with the Newsletter drafting on Github?

  15. wurstsalat

    emus, perfectly happy. It’s pretty easy, you don’t even need to clone the repo

  16. Licaon_Kter

    emus: didn't had time look, albeit I didn't have any news to report either :)

  17. Martin

    emus: It's fine. At least we can startvin markdown and don't have to use wiki syntax and transfer it to markdown later.

  18. emus

    Licaon_Kter: I thought you did

  19. emus

    > emus: It's fine. At least we can startvin markdown and don't have to use wiki syntax and transfer it to markdown later. that was one thought I had

  20. peetah

    It's fine for me.

  21. peetah

    The wiki needs to be updated though to detail current github workflow for new contributors who would not be familiar with it.

  22. emus

    peetah: Yes. I can do so

  23. peetah

    we also need to test the insertion of images from the github repo as discussed some week ago woth Nyco

  24. peetah

    we also need to test the insertion of images from the github repo as discussed some weeks ago with Nÿco

  25. peetah

    emus: thanks that would be great

  26. peetah

    Should'nt the addition of flags according to the language used by links, wether audio, video or text, be located next to the said links , rather than at the beginning of the related text block ?

  27. wurstsalat

    I’d say so, too

  28. emus

    I think at the beginning is fine, as its somehow more unified and people see where its coming from. I also lile to advertise the bunch of local background we have But if you prefer to put it to the links its fine aswell

  29. vanitasvitae

    > wurstsalat, peetah, Martin, vanitasvitae, pep., DebXWoody, Licaon_Kter: So question to the recent contributors, how happy have you been so far with the Newsletter drafting on Github? Not as happy as I thought. Editing by creating PRs adds overhead. While I dont like how dated the xmpp wiki looks, editing was easier there. Maybe we could try out drafting in githubs wiki? A big disadvantage is githubs noisiness when it comes to mails. I received around 20mails from nycos feedback on the draft.

  30. emus

    Hmn okay. So the Wiki is the same markdown format? I thought it would be good to have a merge request to increase the quality and have formulated text from the beginning. Wikis tend to most people drop links, which is much work in the end of the months. And I also prefer to have many people actually feeling they contributed more then just dropping a link

  31. pep.

    https://post.lurk.org/@pep/104426847433984774

  32. Martin

    The show me the results doesn't work for me.

  33. pep.

    ah?

  34. pep.

    What do you mean it doesn't work

  35. emus

    I need an account to vote?

  36. pep.

    yeah, mastodon account

  37. pep.

    It's fine if it's not supposed to be a really broad view, it's obviously a specific subset of the community

  38. Martin

    > yeah, mastodon account Ah, I thought I can watch the result without account.

  39. pep.

    Martin, when it's over :p

  40. Martin

    😢

  41. pep.

    That option is if you have an account and you want results right now. I think it's a shame you can't see results before

  42. emus

    vanitasvitae: would it be possible to switch off notifications? like when creating a PR already

  43. vanitasvitae

    Sure

  44. vanitasvitae

    But I guess it gets re-enabled for each contribution of the user

  45. vanitasvitae

    And also for each new PR

  46. emus

    🤔 thought so. hmm, I think switching to the wiki would be fine, but I still prefer people to write fornulated sentences. A wiki invites to not do so 😐

  47. wurstsalat

    does githubs permission model permit wiki editing for specific users?

  48. DebXWoody

    vanitasvitae: I'm busy, I will come back on this topic this afternoon. Just for technical feedback. I can not provided feedback on github, I don't use it (just for profanity :-( ) .

  49. DebXWoody

    I recommend to use a tool which can md-file format, because at the end of the day it's the format which. The tool should support versions and diff. I think git and a git-frontend should be able to manage this. I also agree, the process should be easy. Maybe some contributors to not have much know-how of git. They should also be able to contribute. Process (proposal) : Day 1 to 31 the newsletter can be managed within a wiki page on git. It's possible to use vim+git+push for the technical members or git frontend for non-technical. You see what you get in the wiki page (md-file will be rendered). I think the access model of github is different as gitlab - no idea. Maybe a now repo for "newsletter" will be an option. Contribution of newsletter should be "open", but not the work o n the official website. After 31 the newsletter will be merged from the wiki git into the repository. A official review phase will start and translation. This should be fine via Merge-Requests.

  50. emus

    I thought about this as well. However if we go back to a wiki Id prefer a stricter policy, as I prefer not to have any links dropped as this was the case in the o'd wiki. Its okay if here and there me or soneone else has to do some work. but not for all links

  51. emus

    many topics I also have no insights and its hard to formulate a decent sentence on the topic

  52. DebXWoody

    I prefer not to have any links dropped?

  53. emus

    Many people just post their links, I saw that in the old wiki. So at the end of the month we had a bunch of links where we had to formulate the News for. I would like to make that a more community based workflow and encourage everyone to do write a few sentences on the news they are dropping. that should at least be the case for most contributions.

  54. DebXWoody

    Link: This should not be a problem - e.g. gitlab has a page edit frontend and the user is able to klick on "link" button to include links in md-file format.

  55. emus

    Hmm, I meant to formulate a text, not about formating links (?)

  56. DebXWoody

    Ah! I see. But this is not an issue which can be solved by a tool. ;-)