14:02:32 #startmeeting websites 11/07 14:02:32 Meeting started Thu Nov 7 14:02:32 2019 UTC. The chair is pili. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:32 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:03:09 here's the pad: https://storm.torproject.org/shared/tliJpj9UpQVTo2fE7nznpsTGQTzDbsU4ZTy09DtFJoi 14:03:16 who's around today? :) 14:03:27 o/ 14:04:44 let me do a call out to others... ;) 14:04:57 emmapeel, hiro, stephw :) 14:06:28 I unfortunately don't have any updates myself for websites work this week :( 14:06:35 ey! 14:06:45 sorry i though we were meeting one hour later 14:06:55 yeah, I thought that might be the case 14:07:00 with hiro we were working on rtl support 14:07:17 I've kept the meeting at 14UTC, so I think it's an hour earlier than usual now 14:08:20 i have updated the different website translations, and there are a lot of new strings to translate in most languages 14:08:43 i have also added new languages to staging because they were more than 40% translated, so translators can have a look 14:09:25 but yeah the support portal and the manual have a lot of new strings.. they have almost duplicated because ggus and the outreachies added a lot of howtos and other documents that were on the old webpage 14:09:29 s 14:10:17 that's good in the sense that we have new content, bad in the sense that there's more work to be done :) 14:10:28 there are still content to migrate from the old faq 14:10:48 but i stopped doing that to organize outreachy things 14:11:02 the progress is documented on dip.tpo 14:12:01 https://dip.torproject.org/torproject/web/support/issues/43 14:12:04 yeah, it is good in the sense that those documents were only available in english until now 14:12:45 there are other small changes and updates too, but a lot is new content 14:12:57 i was thinking on making a call for translation soon-ish 14:13:22 we only have two more months before the year ends and people disappear 14:13:31 (well not even two) 14:15:10 nice ticket ggus ! 14:15:23 I hadn't seen if before... 14:16:48 I saw there's a lot of PRs on the portals 14:17:12 yeah, ggus could probably do with some help reviewing them 14:17:44 pili: i have added new label https://dip.torproject.org/torproject/web/tpo/issues?label_name=Localization not sure if i did it right 14:18:10 looks good, we could possibly even make it at the web group level 14:18:19 it's easy enough to promote it to a group label 14:18:43 that would be nice, so i can see all the tickets at the same time 14:19:00 done 14:19:27 i was wondering, what is the deal with the repeated labels? like doing or todo 14:19:38 we should clean those up 14:19:46 there's probably some from the Tor Project group 14:19:59 that we should use instead of the sub group ones 14:20:02 or the project ones 14:20:41 but essentially they are used for some projects as the kanban board columns 14:20:59 so a label in gitlab can be used as a column in a kanban board for a project or a group 14:21:10 yeah we have that with the needs review etc 14:21:26 but that is why i get confused with the repeated ones 14:21:35 we should probably use the tor project group ones so we can have a global view at the Tor Project board 14:22:16 everyone good on this point? 14:22:19 does anyone else have any other updates to share before we move on to the triage? 14:23:39 i added a discussion point, are we going to have the triage first and then the discussion? 14:24:27 let's do discussion first 14:24:37 as the triage will take a while 14:25:24 I don't see your discussion point... 14:25:30 did you add it to last week's notes? :) 14:25:38 -> Workflow for content update 14:25:49 yup 14:25:58 you can go first in any case 14:25:59 sorry, i pasted on the wrong place 14:26:19 and we can work our way backwards through the list 14:26:49 i'd like to discuss the workflow for updating the documentation 14:27:09 by updating i mean: when a new tor browser release happens, i need to fix a few things 14:27:20 ok 14:27:23 and i understand it's not a feature 14:27:33 since it's not changing css or template or new sections 14:28:36 ok 14:29:05 it can break the build anyway 14:29:36 if the build is breaking because of markdown the problem is other... 14:30:24 yeah but the markdown can break the build 14:30:48 ggus: do you have a proposed workflow already or do you want to go through what you did this time so we can try to figure out the optimal workflow? 14:32:46 pili: we never had a very good workflow. before lektor it was a pain to change things on mallard and it tooks months to someone with git access to change it 14:32:52 ggus: i had to correct several strings that you pushed to the repo, i would like to have the possibility to review your content / markdown commits. otherwise i need to check them once i updated the translation files and some strings that are not ready for translation may end up on the translation platform 14:33:38 we had a woorkflow in which you proposed branches and i reviewed them, we were supposed to do that once a month... but we havent done it so much 14:33:54 on github I think you can set up codeowners for different files then whenever there's a PR modifying those files a review will be automatically requested 14:34:25 so maybe emmapeel could have that for strings 14:34:58 emmapeel: right, there are many things to correct, including broken links that come back from translations, i.e., website footer 14:35:07 0~i tink all code should be always reviewed by somebody else. and documentation is also code. i tend to submit a lot of pushes without review because i am normaly reviewing other content, but i always ask for review of my original content 14:36:19 the footer is part of lego, not related to the translations so much 14:37:48 ok, so, ideally for changes resulting from a new Tor Browser version we'd have a list of changes to make, would those be in one ticket for all the changes or would we want to break them down, e.g by section to be updated? 14:38:11 pili: i did a pad and i went to ux meeting to review with antonela 14:38:19 ok 14:38:26 so i don't think we aren't reviewing the content 14:38:39 we definitely should :) 14:38:44 review the conten 14:38:48 *content 14:38:59 ah sorry, I misread 14:39:42 anyway, my proposal would be that, from a ticket, someone would work on the changes, e.g to add new documentation, build locally, test it looks fine and then request a review 14:40:01 which would probably require: a) pushing the changes to some sort of staging branch/environment 14:40:14 and getting both a content and "code" review 14:40:53 pili: i think we are lacking of content review. who merged your PR to the training section? 14:41:04 me... :/ :) 14:41:07 yeah 14:41:20 ggus: I thought you said it was fine... :) 14:41:55 I think there's also a difference between content and copy... 14:42:19 e.g the changes to the training materials were more about content than writing new lengthy copy 14:43:30 ok, so we have a bottleneck at the review stage 14:43:42 how do we solve that? should we try to do reviews during these meetings? 14:43:47 for content and code? 14:44:04 i can review things. actually, i end up reviewing all the content because i need to review it to send it for translation 14:44:07 for example, do we really need a content review for this? https://github.com/torproject/support/pull/101/files 14:44:08 and then we send on for copy review to steph? 14:44:36 i can review technically etc. sometimes there are things i cannot review, but content usually i can 14:44:52 ggus: I would say yes, even if it's a quick one as a sanity check 14:44:55 if somebody agrees with what it says... 14:45:28 ggus: actually i reviewed that pull. and i was about to make some corrections 14:45:33 ok, so how do we formalise this review process, because we have lots of informal reviewers 14:45:42 pili: i think we are adding a process that is going to create a bottleneck very quickly 14:45:47 with lots of others commitments :) 14:45:54 because i think it is not sustainable to have to change the number for each release. we should add some information that helps us to change that 14:46:24 emmapeel: we should have something automatic. but do we have it now? 14:46:25 like ' replace the version number with the one found at [link] 14:46:33 ggus: I see what you are saying, do you have an alternative proposal? 14:46:41 ggus: we could use databags for that 14:46:46 maybe even put them in lego 14:47:05 e.g the same way we use them when we add a new tor browser release to the download page 14:47:38 that could be one quick fix that would save a lot of manual labour 14:48:08 you see? here we can see one example of why everything needs to be reviewed :) 14:48:38 if people want to improve, go ahead. but let's remember that we all have N other things to do 14:49:06 yup, I was going to say that about reviews also 14:49:13 and how can we manage that 14:49:23 I still think they're important 14:50:05 i think it's important for new sections. for small adjustments is mostly ok to push 14:50:34 and also let's try to find a way to automate these small adjustments! 14:50:54 we have about 10 minutes left, I think I can probably do the triage with hiro at some other point this week 14:51:05 databags, css, and templates changes i'm not putting on my plate 14:51:20 are there some release scripts that maybe the devs use when preparing a new release? 14:51:21 ggus: makes sense 14:51:38 clash: boklm would know that ^ 14:51:58 he pushes the changes when there is a new version of Tor Browser 14:52:13 so I guess it does make sense to skip the review process for things like that 14:52:19 because those could easily update the strings too, stuff like version numbers and so on 14:52:22 I see 14:52:33 we should define what constitutes a change that needs review and what's ok to push 14:52:44 clash: there are no scipts 14:52:44 pili: yes, that is my point 14:52:53 just documentation what needs to get changed 14:53:00 well, with the databags you can just update it in one place if the relevant databag is in lego 14:53:03 in case e.g. a new tor stable gets out 14:53:21 screenshots with new UI is pretty ok to push without review 14:54:27 pili: i dont know how can you access databags from the markdown content. i only see them in the templates. 14:54:52 hmm yeah, I haven't looked into this in depth, it was just something I thought of... 14:56:13 emmapeel: hiro should be able to tell us if it's possible or not, maybe it isn't 14:58:03 so, I see the following outcomes from this discussion: 14:58:29 1) we need to formalise the workflow for changes to the websites when a new release is out 14:58:52 2) we need to define the criteria for what is a change that needs a review vs one that is ok to push directly 14:59:22 3) we need to figure out how to avoid bottlenecks in the review process 14:59:53 I think the metrics team meeting is not happening today but we should move this on to #tor-www 14:59:56 we're at the hour 15:00:01 #endmeeting