13:59:54 #startmeeting www 13:59:54 Meeting started Thu Feb 27 13:59:54 2020 UTC. The chair is hiro. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:59:54 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:00:01 #topic migrating the blog 14:00:10 okk 14:00:23 hello 14:00:27 let me find the corresponding ticket 14:00:39 hi 14:01:01 hello! 14:01:15 #link https://trac.torproject.org/projects/tor/ticket/33115 14:01:52 ok the summary of this ticket is that we would like to migrate the blog to a static website with lektor 14:02:18 comments will be provided by discourse that has kindly offered to give us a hosted discourse instance and make it also available via onion service 14:02:44 something we may need to discuss about migrating the blog is having comms on board on what we are going to pick as a cms. I don't think we will do a good move if we will rely on PR approvals for submit a blogpost. 14:02:46 hello everyone :-) 14:02:53 dont get me wrong, i love the idea to get ride drupal 14:03:05 drupal is also expensive 14:03:09 antonela: i agree, thank you 14:03:20 but if i need to make a PR for people who cannot do it, is complicated 14:03:56 I think there are enough people that can merge a post into the websites for this not to be a problem 14:04:21 but sometimes it can be days or longer for something to be addressed, so it adds in this effort to have to bug people a lot 14:04:27 which isnt good for several people 14:04:29 at least considering that to pay for the blog we are not getting other stuff that can be more useful 14:04:49 I think we may need more coordination between mergers and content publishers 14:04:50 it will be much better for me and my work if i can do it directly 14:04:54 and the current frequency of posts is about 2 a month 14:05:08 but sometimes there are edits we are not considering 14:05:17 and they happen without any notice 14:05:26 maybe we can compare the existing workflow now with the proposed workflow 14:05:54 well the other option is allow me to to be an admin which makes a lot of sense given my position 14:06:40 i would not mind stephw being and admin if she could have a way to test her edits before pushing. in our current setup, editors can break the whole website even with a little markdown error 14:06:51 sorry i'm late 14:06:57 had trenches to dig 14:07:02 nasty weather this morning 14:07:02 I think we can have a different setup for the blog 14:07:09 in which steph can push directly 14:07:20 yea and ive had power with other nonprofits ive worked for where it is possible i could break the site, so i get it, it's not going to be an issue 14:07:37 as long as i can preview then it should be okay. 14:07:40 +1 for giving stephw more powers :) 14:07:43 yeah, preview 14:07:45 thanks pili 14:07:53 the power of preview is a good one 14:07:57 ;) 14:08:16 i think steph and people that we agree in our blog account policy: https://trac.torproject.org/projects/tor/ticket/33109 14:08:19 the problem with the current website is not about breaking the website which is minor 14:08:31 fwiw, my 2cts from Tails' side: we don't rely on Tor blog to publish time sensitive info, it's fine if it take a couple days for a blog post PR of ours to be approved. And if the risk of merging it ourselves is "possibly break Tor's blog", I'm pretty sure our release managers will prefer someone else to validate and take the responsibility to approve the new post ;) 14:08:53 i can take care of tails' posts 14:09:19 intrigeri: i would love to get a heads up before you post either way just to see if theres anything i can help with or add an img, etc 14:09:20 * anarcat caught up 14:09:31 emmapeel: much appreciated :) 14:09:50 sorry i never realised this bridge needed to be built. it is easy for me as i participate on the Tails release process 14:10:36 although i dont write to the blog often 14:10:55 all good emmapeel! i think we talked about it but it doesnt happen often it's been fine 14:11:24 stephw: ack. Our most common blog post is major release announcement (~twice a year), copied from our release notes, and our tech writer usually provides images to go with them. Taking note about coordinating with you, will bring this back to my team. 14:11:30 last tails blog post is about Tails 3.12, we are on Tails 4.3 now 14:11:49 intrigeri: thanks! i usually go in and add an image and a summary point, minor stuff 14:12:00 but in the new proposal now i would have to get someone else to do that 14:12:05 so i do hope we make me an admin 14:12:06 stephw: thanks for doing this, I did not know! 14:12:18 what is an admin? exactly? 14:12:43 i think on this context admin==commit bit 14:12:44 we can give you the option to push to the blog via git 14:12:51 this has never been a problem 14:13:03 in this context someone that can edit the blog directly 14:13:10 but you will need to know some basic git commands 14:13:24 fine 14:13:39 (or use github desktop, which can do the same work with some clicks) 14:13:40 stephw: i can help you on that 14:13:48 emmapeel: thank you 14:14:02 yes totally github desktop can work 14:14:25 i suspect that it might be possible to edit the blog directly through the gitlab web interface too, no? 14:14:37 yes that too 14:14:39 yes, too 14:14:44 but we do not publish from gitlab atm 14:14:55 so at the beginning we will have to find a way to go around that 14:15:04 or publish the blog from gitlab 14:15:23 in fact we could decide to wait on migrating the blog until we have gitlab pages 14:15:31 if that's where we want to go 14:16:07 i just tested in https://gitlab.torproject.org/anarcat/test/ and i could edit the README without issuing a pr 14:16:13 but yeah, of course that means using gitlab :) 14:16:25 i was assuming that was a prerequisite, but it's true we haven't made that jump just yet 14:16:42 ideally I wanted to move the blog before gitlab pages 14:16:49 as gitlab pages isn't even on our roadmap 14:16:59 correction: the blog has more posts, only https://www.torproject.org/press/ has Tails 3.12 but the blog has more 14:17:06 so in that sense the github desktop app can be handy 14:17:12 well won't don't neeed gitlab pages, do we? 14:17:36 we just need a git repo on gitlab, and to fire the right hooks (to jenkins? or just push back to git-rw...?) 14:17:57 yes we can do that 14:18:01 i don't know about requiring people to use proprietary software, to be honest :) 14:18:11 if people publishing are okay with that as a temporary measure, i guess that's fine of course 14:18:19 yeah no proprietary plz 14:18:21 it's a matter of policy that we have a webapp publishing to one of our git repositories that goes inot one of our websites 14:18:27 but i know what "temporary measures" can mean :p 14:18:28 in the past this flow would have been a nono 14:18:52 hiro: sorry, what's a nono? 14:19:02 a double no? 14:19:08 a no-no 14:19:09 so a yes? :) 14:19:12 super-no 14:19:17 yeah a super no 14:19:17 no i mean what policy is a "no" :) 14:19:21 ok 14:19:31 i don't understand which policy you're refering to 14:19:36 i understood the nono part :p 14:19:38 so it's not written 14:19:44 no² 14:19:45 i think comms folks could try gitlab/github as blog platform and write a short feedback 14:19:55 (this is hilarious: "nono" in quebec french, means "silly" :) 14:20:27 I said in the past having a web app that would push to one our git repository and be published on one of our website would be frown upon 14:20:35 that web app being gitlab 14:20:38 maybe if we give stephw the ability to push branches that get built by jenkins, she will have a nice preview on jenkins to test before pushing to msater 14:20:53 yeah ^ 14:21:19 we can also have a lektor install protected by password, where she can use the 'local' editor. but that will not be so safe 14:21:43 lektor can also be used locally 14:21:46 hiro: i see 14:22:01 hiro: that's a strange requirement for the blog, considering how it works right now :) 14:22:12 lektor can be used locally but a lot of our team is not able to do so 14:22:21 we should work on empowering editors to have a local install 14:22:31 yeah, i wouldn't ask people to compile the website before publishing, that's even harder than pushing the git repo, imho 14:22:39 anarcat the blog is not on our infra. don't get me wrong I am ok with that. I am saying that in the past this approach would not have been accepted 14:22:43 as i said, i don't object to github desktop or something similar as long as it's temporary 14:22:53 hiro: okay! :) 14:23:02 water under the bridge? :) 14:23:14 i mean if there's a written policy that says we can do that, of course we need to look into htat 14:23:25 compiling the website can be hit and miss even when you (supposedly :) ) know what you are doing 14:23:31 but if it's "but someone might be against this", maybe those persons can say so instead of us second-guessing them? :) 14:23:53 it is hard for me to evaluate these specific options since i have not done them 14:24:05 honestly, if we're going to adopt gitlab, a lot of those (formal and informal) policies are going to change 14:24:11 just by the inertia of it 14:24:20 yeah 14:24:30 but i would of course appreciate the simplest, fastest, most intuitive option :) 14:24:40 maybe we could give stephw an account somewhere so we can test those various options? 14:24:44 what do we have left on the board? 14:24:47 github desktop? 14:24:51 gitlab web editor? 14:25:07 anarcat: and I am ok with that. I have just to mention what was the status last time something like this was suggested before someone^TM jumps onto to me 14:25:27 anarcat also gitlab web editor is already being used to do review of the community and support portal 14:25:30 hiro: yeah, i'm glad you did so 14:25:31 github desktop is not for edits, github desktop is for managing git 14:25:45 antonela: that's what i was wondering too 14:25:49 like basic things: fork, push, pull, and stop there 14:26:08 im using the terminal for other things like submodule update 14:26:09 all those website are synced into the personal repositories so that people can do PR almost auto-magically 14:27:49 * antonela https://desktop.github.com/ 14:27:51 can we give one step back and think about other static solutions other than lektor that might be simple to someone and edit and preview? for example, anarcat pointed that hugo has some CMS/app clients, maybe we could investigate that too? I remember that the reason we chose lektor was l10n support, but this doesn't apply for the blog. 14:27:58 well... they may look automagic to them but there is some work on the backstage. for example, bekeela's edits cannot me merge, i need to cherry¡pick, because she add a lot of gitkeep files and others 14:28:44 ggus everything we are now using is based on lektor from the styleguide to templateing 14:28:52 ggus: i don't remember hugo having some CMS/desktop app, tbh 14:29:06 ggus: and if hugo has such an app, it's likely it can be also used for lektor 14:29:06 anarcat: you mentioned last week? 14:29:08 I don't have the resources to put the blog onto antoher framework 14:29:11 ggus: i did? 14:29:11 ggus: i rather invest some energy on our current CMS than to have different CMSs hanging around. lektor was chosen because it had a local edit option, mayeb it is easier to fix it than to install another CMS 14:29:23 I have a lektor app that I have been working on 14:29:28 i'd also be hesitant in switching CMSes 14:29:33 is lektor using standard markdown, that could be edited with local markdown editors? 14:29:43 boklm yes 14:29:45 yes 14:29:59 (research.tpo is hugo, because i couldn't make lektor work) 14:30:16 we could have a server with a lektor, accesible through an onion service, that editors can use and we can make PRs from 14:30:18 * boklm doesn't know what markdown editors exist, but maybe some good one exists 14:30:33 i would have gone with hugo as well, honestly :) 14:30:35 * antonela use atom, and is happy 14:30:39 but i don't want to open that can of worms now 14:30:51 i'm following hiro on that one :) 14:30:52 (but if it becomes super easy to make lektor sites go then maybe we should move research.tpo that to lektor) 14:30:59 yeah 14:31:14 problem with "standard markdown" is it's not a thing 14:31:23 can we not disgress? 14:31:27 yeah 14:31:30 let's not :) 14:31:31 i think we need to spend some time with our not-so-tech editors and help them to have a local install 14:31:50 thanks I think we all have our preferences and issues with this tool or the other but this isn't the forum to discuss it 14:31:58 so they can test their posts before publishing 14:32:20 im talking about requirements for the new blog... not sure if im digressing 14:32:24 emmapeel: one way that could work would be through a PR workflow though :) 14:32:44 you push to a your fork, make a PR, then CI builds a test website, and if it looks good, you merge it 14:32:51 also I have been working on this: https://github.com/hiromipaw/ghostwriter it's a desktop app for lektor but I haven't had time to finish it 14:33:02 emmapeel: re digressing, i think hiro was refering to me and hugo :) 14:33:03 anarcat: yes, but editors could make a PR once they are happy with the contents. atm the editors send a PR without being able to compile 14:33:17 it packs lektor and shares via onion 14:33:19 editors are attaching a .txt file, is not even a pr 14:33:20 so that could be a solution 14:33:25 hiro: nice 14:33:30 but it's not finished so that's another digression we shouldn't take 14:33:39 I think we should concentrate on the blgo and gitlab 14:33:57 emmapeel: i'm not sure i follow 14:34:06 antonela: that workflow would change :) 14:34:30 i hope 14:34:41 so we can agree to have the blog edits via gitlab 14:34:47 and that's built via jenkins 14:34:50 imo the best move is first put efforts on make pr available in gitlab again, so people can use the gitlab ui as an editor 14:34:54 so that will make the transition easier 14:34:55 anarcat: i agree with your workflow. what i mean is that now, people edits in github or gitlab and sends the PR without seen the preview. if we could help them review after compiling, the styles and little link errors wil be solved 14:35:01 i think is the best thing at the moment 14:35:31 antonela the PR issue is solved in gitlab.tp.o 14:35:39 nice 14:35:39 nice 14:35:44 and that will substitute dip next week probably 14:35:54 glory 14:35:56 hiro: antonela I think you are both talking about the same thing and I would agree, it would be useful if we explain what that entails so that we are all on the same page 14:36:25 are you saying that people would work on their gitlab mirrors and issue a PR through there 14:36:45 pili we can do both 14:36:56 ftr: i have fixed small errors not only on stephw's PRs, but also on kushal's, egypcio and others. 14:36:56 we can manage permissions differently with the blog 14:36:56 if so, what happens once the PR is issued? what's the workflow after that 14:37:00 that with the other websites 14:37:23 we can have blog editor write directly on the blog master... or if they want to work on a draft on their own repositories 14:37:32 and then do PR and merges via gitlab web interface 14:38:13 ok 14:38:35 how would previews work in this scenario? do we still want to do them? :) 14:38:42 in the long run, i think it might be better to enforce a PR workflow 14:38:45 so that we have previews 14:38:45 yeah, plz previews 14:38:56 otherwise the content suffers 14:39:01 and the reviewers also :D 14:39:06 but in the short term, we could live with the existing gitlab text editor preview functionality maybe? 14:39:09 def need previews 14:39:10 yes 14:39:26 also i suspect the "preview" concern might become a non-issue with lektor, because "breaking the blog" wouldn't happen in the same way 14:39:43 the preview can happen if we use branches 14:39:57 but what is breaking? a missing ] does not break the blog, but the link is broken 14:39:59 so these are built as now branches are built into our lektor-staging.tp.o folders 14:40:20 do i understand correctly that posts can break layout in the current blog? 14:40:22 or maybe you use an h5 heading, but it looks too big for the title 14:40:25 or did i misunderstand that 14:40:36 anarcat I think you misunderstood 14:40:51 and I think emmapeel used a slighlty too strong tone 14:40:56 that she is now correcting 14:41:13 summary: you can break a little bit the way stuff is displayed 14:41:26 like you might have a broken link because you have forgotten a [ 14:41:34 or some heading can be too big or too small 14:41:47 we could also have a template of a blog post to make that more difficult to break 14:41:58 so that people can fill up the various parts 14:42:12 without worrying too much about checking one too many markdown cheatsheets 14:42:30 right 14:42:34 it is easier to learn if you can preview your changes 14:44:04 we have about 15 minutes left, what do we want to get out of this discussion? A decision to go ahead? A list of concerns to be addressed before we move on? 14:44:17 a decision to go ahead would be nice 14:44:27 i'd like to understand how discourse comments would work. 14:44:28 a list of concerns could become a table of requirements 14:44:56 ggus we would embedd them via JS 14:45:04 and each post will become a forum topic 14:45:26 hiro: the above sounds good to me, anything else people would like to achieve from this discussion? 14:45:28 so people can continue discussing on the forum if they wanted 14:46:29 ggus: examples of embedded discourse comments https://blog.codinghorror.com/is-your-computer-stable/ https://pixls.us/articles/processing-a-nightscape-in-siril/ 14:46:57 https://meta.discourse.org/t/embedding-discourse-comments-via-javascript/31963 14:47:15 haha anarcat sme thinking 14:48:00 :) 14:48:37 the good think is that discourse moderation should be easier than drupal as it is developed and designed to make communities ealthier 14:48:43 *healthier 14:48:48 so people will need to create account? we will need moderators? could you explain more about this comment workflow? 14:48:54 s/think/thing 14:48:56 and can we provide link to discourse forum for non-js users? 14:49:02 boklm no 14:49:17 as you now need JS to comment on durpal 14:49:26 ok 14:49:44 ggus: i'd say 1) yes 2) yes 3) yes 4) maybe? 14:49:48 ggus people will need to use an account on our discourse but we could also create a shared account if we wanted and make the password known 14:50:08 and as we do now with the blog comments people will need to moderate 14:50:47 (both examples i pasted require javscript to show comments and, in general, discourse is javascript-heavy) 14:51:07 yes discourse is in fact an emberjs application 14:51:18 and the backend is rails 14:52:16 will we moderate comments before they are visible (like we do now), or is it moderation only after they are published? 14:53:35 there are different moderation permissions to be honest 14:53:36 can we also have new forum topics closed/reserved only for moderators? so we can have only topics for the blog posts 14:53:57 an example is this one: https://meta.discourse.org/t/discourse-moderation-guide/63116 this is how topic are moderated on discourse own forum 14:54:21 moderation is the best think discourse have https://meta.discourse.org/t/discourse-moderation-guide/63116 14:54:24 there you are 14:54:32 s/think/thing 14:54:55 same thinking again :) 14:55:25 (5 minute warning :) ) 14:55:48 sstevenson: will open a ticket for your requested changes in the donate flow and will ping you for review 14:55:58 sstevenson: probably next week 14:55:58 thanks! 14:56:18 there is also a trust system within discourse that user can have 14:56:25 https://blog.discourse.org/2018/06/understanding-discourse-trust-levels/ 14:56:45 ggus: there are private forums, yes 14:57:07 i don't know if there's a "pre" moderation workflow 14:57:42 hiro: maybe it would make sense to give ggus and others an account on the test discourse instance so they see what it's about? 14:58:09 metrics meeting in 1 minute, we can go to the other room if you need more time 14:58:10 yes 14:58:12 ok, looks like there are many options 14:58:18 we can open that up 14:58:26 we need to free the channel 14:58:27 irl: we can move to #tor-www I think 14:58:33 you can have the room 14:58:36 cool thanks 14:58:38 please comment on the trac ticket if you have any more questions 14:58:43 #endmeeting