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