14:01:35 <pili> #startmeeting website launch retrospective 04/11
14:01:35 <MeetBot> Meeting started Thu Apr 11 14:01:35 2019 UTC.  The chair is pili. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:35 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:01:37 <pili> that didn't work...
14:01:41 <pili> there we go, a bit slow
14:02:31 <ggus> hola!
14:02:48 <pili> before we get started, I would like to share the prime directive: http://retrospectivewiki.org/index.php?title=The_Prime_Directive
14:03:00 <pili> so we can bear this in mind during the retrospective :)
14:03:35 <pili> we want to divide the meeting in 2 parts:
14:03:57 * GeKo is still waiting for The Prime Directive showing up in tor browser
14:04:11 <pili> part 1 will be to list the events leading up to the website launch, from the weeks leading up to the launch, to a few days before the launch and after
14:04:36 <pili> during this part we can talk about what happened, what went well and what we can learn for next time
14:04:49 <emmapeel> yeah i cannot read this directive neither :S
14:05:26 <arma1> "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."
14:05:45 <pili> part 2 will be discussing what we will do differently for the community portal
14:05:49 <pili> does that work for people?
14:05:50 <GeKo> thx
14:06:50 <pili> (part 3 will be discussing how the community portal launch is going if we have time to discuss)
14:07:36 <pili> anyone want to start? otherwise I can start listing what happened :)
14:08:31 <pili> ok, I'll go then :)
14:08:32 <arma1> sounds like you should start :)
14:09:18 <pili> so for the past few months, members of the UX, comms and community team have been meeting regularly to discuss the new website, including the new illustrations and content
14:09:36 <pili> regularly = about once a week
14:10:28 <pili> once we were happy we had a consistent visual language and were ready for launch, we shared the staging website with tor-internal list for feedback and testing
14:10:33 <pili> this was done in early february
14:11:00 <pili> we were mainly looking for broken link reports as well as visual bugs
14:11:46 <pili> we had a week to collect this feedback and we started working on the tickets created as a result of this exercise
14:12:15 <pili> this process was finalised mid-late February
14:12:32 <pili> from then on antonela and hiro started working on fixing those reported issues ready for our launch
14:12:54 <pili> at the same time we had emmapeel working with translators to get as many languages fully translated for our launch as possible
14:14:14 <pili> through discussion on the regular website sync meeting, we decided to finally launch the new website halfway during the week of the 25th March
14:15:06 <pili> we decided to do a silent launch on the tuesday 26th to allow us to fix any issues with the live website before we announced it to the world on the wednesday 27th
14:15:15 <pili> I feel like a lawyer :D
14:15:22 <emmapeel> :D
14:15:24 <isabela> (is good tho :)
14:15:48 <pili> we had a few issues with the jenkins instance on the day of the silent launch
14:17:05 <pili> it seems like it can take a while to trigger the website build unless the slaves are also triggered (hiro has more details on this if anyone is interested) which caused some delays in publishing the new website
14:17:35 <hiro> it's not exactly the website build
14:18:02 <pili> as well as that there were a number of broken links which had to be manually fixed by hiro, which takes some time to do
14:18:16 <hiro> it's the jenkins job... I didn't know I had to pull in all the slaves... usually isn't needed. So .htaccess wasn't syncing
14:19:56 <pili> one other point is that we launched with less languages than we were planning to at first as we didn't get as many as we wanted fully translated
14:20:23 <pili> but that turned out to be not so bad as apparently the website launch motivated a number of translators to finish off their languages :)
14:20:33 <isabela> :)
14:20:34 <pili> anyway, I think that's all I had to share for now, I would like to open this up to others
14:22:29 <pili> any feedback or comments from anyone? :)
14:22:30 <arma1> (seems like a lot of people are being quiet to let others talk. that's what i'm doing at least.)
14:22:46 <emmapeel> regarding translations, i think people is interested to translate but it does not work on short notice... so maybe next time we should not block the release for that, but go adding languages as they get translated. Also because some strings get changed last minute and there is a stress of freezing and sending to translate, etc... maybe we can skip this stress
14:23:13 <isabela> agreed
14:23:25 <arma1> emmapeel: does that imply maybe a longer quiet-launch period?
14:23:49 <antonela> more staging time? or more time live without social media noise?
14:23:52 <arma1> on the theory that the press announcement wants to happen when there are some languages
14:23:53 <emmapeel> arma1: no... just maybe launch in english and spanish and then in 3 days having more langs
14:24:00 <isabela> yeah
14:24:01 <isabela> just launch
14:24:09 <isabela> and use the buzz to get folks engaged :)
14:24:32 <arma1> sounds like a useful step
14:25:24 <emmapeel> maybe each time we launch a new language we could make some noise too. today i have added Georgian and Icelandic that were finishd.
14:25:34 <stephw> great happy to share that, keep me updated
14:26:09 <isabela> (can we keep these useful new steps listed on a pad?)
14:26:13 <arma1> antonela: 'more time live without social media noise' was what i had meant
14:26:27 <pili> isabela: let me create one quickly
14:26:49 <antonela> great, i agreed
14:26:51 <stephw> well we cannot control all of social media
14:27:06 <stephw> so people started talking about it before we do
14:27:17 <antonela> its fine, we cannot control it
14:27:18 <stephw> so having that be as short as possible is best from the comms side
14:27:37 <antonela> but we need time to fix this kind of things that only happened in live domains
14:27:52 <stephw> yes i understand, i am just telling what happens from this side
14:27:56 <irl> why do things only happen in the live domain?
14:28:02 <irl> that seems like we've got a bad staging env
14:28:11 <pili> https://storm.torproject.org/shared/JozR2ypLQhRca6h5ZapFBfIQbnCwLs0UkSDUw4XBgBD
14:28:41 <hiro> irl it is not a matter of staging in this case... we are splitting a website in 4 or 5 different website
14:28:54 <hiro> we have things that are around that we didn't think of
14:29:23 <irl> ok, but we can fake the domain names for testing, we shouldn't need to still be doing testing on the live site
14:29:27 <irl> maybe i do not understand
14:29:44 <hiro> yes it's the other way around
14:29:47 <sysrqb> also, to be fair, this is the first time the main website was significantly changed, i think there were many lessons learned
14:30:06 <irl> yes, of course, i'm wondering if one of the lessons is that we need a better staging setup
14:30:06 <GeKo> let's keep those lessons somewhere written
14:30:07 <arma1> well, first time in a while :)
14:30:16 <ggus> irl: for example, links in the google search pointing to the old website pages, that doesn't involve a good env staging.
14:30:22 <hiro> so we have to think of the links from what we have still live in the old website and in other pages/projects around
14:30:34 <hiro> how those map to what we are changing
14:30:35 <GeKo> ggus: +1
14:30:43 <sysrqb> yes :) (first time in many years)
14:31:07 <irl> did we have a full map of old urls to new urls with redirects?
14:31:12 <hiro> so we think we redirect certain patterns to new things, but we also have to redirect some things to old things because of how the information is changing
14:31:19 <antonela> someone told us that you can help us on it irl
14:31:27 <hiro> and we have this mapping
14:31:33 <hiro> but some things slips
14:31:48 <hiro> also because of all the redirects we had on our old .htaccess
14:32:00 <arma1> yeah, it seems like whatever the process was for making that mapping beforehand, or shortly after, could be improved
14:32:12 <hiro> and because some pages (like all the different donate pages we have...) redirect to even older things
14:32:35 <arma1> i guess that particular issue won't be as bad for the next website launches, because they are not replacing existing sites. is that true?
14:32:52 <isabela> well
14:32:56 <hiro> uhm... not really...
14:33:01 <isabela> some content will be replaced in those portals
14:33:10 <isabela> stuff that is on 2019.www
14:33:20 <hiro> also some content is being updated giving that we have another website
14:33:46 <antonela> https://docs.google.com/spreadsheets/d/1hoceLEYevlxbVu5z5g7mdCPoBuhv6e0xJ3bRPEYWv4A/edit#gid=0
14:33:47 <arma1> ok, so it seems like coming up with a smoother way to do redirects is a really important step to improve on
14:33:54 <hiro> personally I do not think we had a lot of pain... it wasn't like the website was down or something terrible happened
14:34:01 <hiro> we had a few issues
14:34:07 <arma1> and by 'do redirects' i guess i mean 'notice that a redirect should be done, and then do it promptly and accurately'
14:34:17 <irl> is anyone using webstats to see what urls people are hitting often to prioritise those for redirects?
14:34:19 <hiro> and a little bit of broken links for a few hours
14:34:33 <hiro> irl I am checking the apache logs to be honest
14:34:43 <arma1> irl: i logged into one of the webservers and looked at the 404's in the web logs. that's how i filed some of the tickets.
14:34:45 <isabela> i heard folks are using apache 404 logs too, to catch things we missed
14:34:50 <arma1> but i only did it a while after
14:35:01 <antonela> irl, nope, that is one of the main reasons i shared fathom yesterday https://github.com/usefathom/fathom
14:35:03 <irl> you shouldn't need to log in to the host, our web logs are in collector
14:35:08 <irl> they are public
14:35:25 <arma1> irl: how long is the delay before they get to collector?
14:35:30 <irl> a few days
14:35:41 <arma1> that seems not best, for this situation :)
14:35:53 <irl> right, but maybe a takeaway here is that we need to improve on that
14:35:55 <irl> for metrics
14:36:01 <emmapeel> i reacted to users on irc, but i have no access to the logs
14:36:06 <emmapeel> (that i know of)
14:36:27 <arma1> though there is a little piece of me that wonders if all the 404's could have been predicted, that is, look at what pages are loaded on the old site, and what pages exist on the new one, and you don't actually need to launch to know the answer.
14:36:47 <hiro> arma1: most of the 404 were predicted
14:37:38 <hiro> the problem was that there was a typo in my jenkins job, right in the script where I said $ cp .htaccess public/
14:37:45 <hiro> so I noticed this and fixed the script
14:38:04 <hiro> but this didn't sync right away in the building job
14:38:31 <hiro> and it did about 4/6 hours later, when I went to pull the diff in all the jenkins slaves
14:40:01 <arma1> i think that was one issue, but also there were 404's that remained for a while. maybe because the old .htaccess maze was confusing.
14:40:20 <arma1> can we think of concrete ways to do it better next time, either to have it better at the start, or to cut down on time-until-fix?
14:40:34 <sysrqb> i suspect some people had bookmarks for pages on the old site, and they did not go to a real page on the new site
14:40:46 <hiro> jenkins synced around 10pm my time
14:40:53 <hiro> then I went to bed and fixed the rest in the morning
14:40:56 <arma1> sysrqb: yes, this is certainly true for external documentation and web pages and so on
14:41:03 <hiro> that also why they staid for a while
14:41:14 <hiro> *stayed
14:41:17 <irl> i believe that a 404 can be cached, which can be a problem
14:41:32 <arma1> irl: cached where?
14:41:47 <irl> it's a "permanent error" so it's expected that if a thing is 404 then it stays 404
14:41:57 <hiro> I think we had 404 for like less than 24 hours.
14:42:00 <irl> so either delete something from a search index or cache in the browser or anywhere that caching occurs
14:42:11 <sysrqb> we*sel decreased the cache time on the webserver, i believe
14:42:19 <GeKo> hah
14:42:31 <hiro> yes weasel did while we were in this "silent launch"
14:42:36 <boklm> maybe we can extract all working urls from the old website using collector, and have a script to check that they all work on the staging website?
14:42:50 <irl> that should be entirely doable
14:43:05 <sysrqb> sounds like a nice automated test :)
14:43:08 <arma1> boklm: i really like the idea of automation here
14:43:31 <arma1> boklm: i think there are a bunch of files from the old site which people were fine with breaking though. like, images. but i'm not sure what the goals actually were.
14:43:32 <sysrqb> now, *who* has the cycles for this? :)
14:44:11 <sysrqb> i don't think it's fair to put all of this on hiro
14:44:12 <hiro> sysrqb: that's another issue. website ops and dev is only me.
14:44:17 <sysrqb> right
14:44:20 <irl> i could run our webstats through awstats on an ec2 thing
14:44:51 <arma1> for example, https://www.torproject.org/images/how_tor_works_thumb.png is still 404 right now, but it is linked from all of the relays that publish tor-exit-notice.html.
14:44:54 <sysrqb> also, i don't think it was said yet, but thanks hiro, antonela and everyone who worked on this
14:45:34 <GeKo> +1
14:45:51 <arma1> yes! great point. overall we succeeded. let us not forget that. :)
14:45:52 <isabela> +1
14:45:53 <boklm> +1
14:46:14 <hiro> the assets pipeline is different from the new website... if we care about images I can redirect all of them
14:46:21 <hiro> to 2019
14:46:49 <irl> i think that creating redirects that no one is using is probably just making more work for ourselves and our future selves
14:46:52 <arma1> hiro: what is the process for making that sort of decision?
14:47:03 <arma1> hiro: like, who is supposed to decide the answer to 'if we care about'
14:47:24 <antonela> angry people on channels or mailing lists is not the answer, for sure
14:47:25 <hiro> I had a mapping spreadsheet of pages and content and worked with that
14:47:31 <isabela> yes
14:47:36 <pili> just as an organisational point, I think we're already doing it, but we should concentrate on part 2: what can we improve for the next portal launch
14:47:37 <pili> also we have a little over 10 minutes :)
14:47:42 <isabela> arma1: i tried to organized that
14:47:45 <antonela> and i pasted it some lines above
14:47:57 <isabela> i did not think of images but we did mapped the urls and organized them in categories
14:48:16 <isabela> so we can track what will stay as it is after all the new portals are done etc
14:48:33 <hiro> that's exactly the point. we can't eliminate the pain giving the complexity of the information we have
14:48:55 <arma1> ok. since we're low on time, let me add another concrete thing that i think will be helpful for the next one: we need to prep our 'front line bug receivers' with how they should report bugs and what they should expect in terms of fixes
14:48:57 <isabela> letme get the url for the spreadsheeet
14:48:58 <hiro> there are things that we can't anticipate because we do not know where and what links to some bits
14:49:15 <antonela> isabela https://docs.google.com/spreadsheets/d/1hoceLEYevlxbVu5z5g7mdCPoBuhv6e0xJ3bRPEYWv4A/edit#gid=0
14:49:21 <isabela> (this was step zero, done like 2years ago or something
14:49:32 <arma1> like, the folks on irc and twitter and reading blog comments and mailing list threads... they filed trac tickets sometimes. but they weren't sure whether a thing was intentional or was a mistake. or who was supposed to decide.
14:49:55 <arma1> and that made the loop between 'bug noticed' and 'bug fixed' longer than it needed to be
14:50:06 <antonela> that is the point
14:50:09 <antonela> who should do it?
14:50:15 <isabela> hmm
14:50:20 <hiro> the loop can't be made much shorter because in the end the bug fixed point is always me
14:50:23 <isabela> i am confuse here
14:50:24 <arma1> who should do what. because there are several 'it's here
14:50:30 <hiro> and I can process as many bugs per hour
14:50:50 <antonela> who should reply the lists, extract the issues, open tickets, read social media, open tickets?
14:50:53 <GeKo> that's a different issue
14:51:04 <GeKo> from the one arma brought up
14:51:18 <GeKo> to give an example
14:51:27 <GeKo> take #29934
14:51:40 <GeKo> i read that on tor-relays
14:51:47 <isabela> i am confuse to what is being asked
14:51:49 <GeKo> and it seemed pretty reasonable
14:51:54 <GeKo> so i filed a ticket
14:52:03 <GeKo> but is it a ticket worth at all?
14:52:06 <GeKo> i don't know
14:52:11 <antonela> everybody is trying to reach it and cannt open, but i think is related with the download pagfe
14:52:27 <antonela> oh css one
14:52:39 <GeKo> it's about the css media rules mixup
14:52:39 <arma1> "#29934: CSS media rule mixes all types of screens together"
14:52:46 <isabela> hmm
14:52:59 <GeKo> the answer on the ticket was "it's bootstrap"
14:53:03 <antonela> seems like that person doesn't have any idea how bootstrap works
14:53:18 <isabela> regarding this question
14:53:26 <GeKo> well, that's not important
14:53:31 <GeKo> how bootstrap works
14:53:48 <isabela> isnt this the same for any release? whenever anyone comes to open a ticket? i mean we have tried to indicate how to report a bug and centralize it on a main ticket
14:53:50 <GeKo> the important thing is whether our website is accessible and working well
14:53:54 <isabela> so folks can see what has been reported
14:54:01 <antonela> https://getbootstrap.com/
14:54:32 <ggus> regarding about feedback and reactions, i think we should have someone from the community team doing this for the next website release
14:54:36 <antonela> is important, because the point is that we are overriding all the css media queries, and it was not the reality, is not how it works
14:54:54 <hiro> GeKo in a way bootstrap makes our website more accessible and working with different devices that the old one
14:55:08 <isabela> and we did asked maggie to do that too
14:55:15 <gman999> on ggus' point, the call for comments should be made early publicly
14:55:16 <isabela> keep an eye on reactions etc
14:55:17 <isabela> no?
14:55:36 <pili> isabela: actually, not for the website
14:55:37 <gman999> so there's something to point to for those who want to be involved in the process.
14:55:37 <pili> we did that for the browser releases
14:55:59 <ggus> yes, but i don't know if she got my email
14:56:06 <irl> did we ever have a banner on the website to explain the new website and how to provide feedback?
14:56:07 <pili> ah, ok
14:56:16 <arma1> irl: great question. i think no
14:56:20 <antonela> no, we should
14:56:22 <isabela> ggus: got it
14:56:35 <isabela> ok
14:56:42 <isabela> so we should list on the pad that
14:56:43 <antonela> and also a link to back to the previous website for people who is uncomfortable with changes
14:56:50 <isabela> because this is what maggie does :) she is our user support
14:56:55 <isabela> she collects feedbacks :)
14:57:01 <gman999> even just another comment on tor-talk
14:57:21 <antonela> the toxic thing happened in tor-talk was surprising for me
14:57:28 <arma1> i think there are two pieces to the feedback. one is how people should report it. and two is the feedback loop where people who report things know whether it's being addressed or whether it even counts as a bug.
14:57:29 <antonela> even twitter nor reddit was that hard
14:57:59 <isabela> arma1: we explained how to report on blog post and on the email to internal (asking ppl to test stuff)
14:58:14 <antonela> yes, both times
14:58:19 <GeKo> hiro: i think it would be worth getting back for you or anyone else who knows more of the bootstrap thing than me and explain why the behavior described is not a bug then
14:58:30 <GeKo> right now it looks as if we don't do our job well
14:59:05 <hiro> GeKo: I think we are afraid of people judgind us
14:59:17 <GeKo> who is "we"?
14:59:26 <hiro> I am talking generally
14:59:39 <irl> if the explanation of things was on the blog, linking to it in a banner on the website gets us both users being happy that they understand and know how to report issues, and also drives traffic to our blog
14:59:44 <antonela> so, hiro and i we need to read horrible people saying horrible things, file tickets trying to get some positive feedback from that, working on those tickets, close those tickets and make sure that we are doing our job well
15:00:15 <GeKo> antonela: i don't think so
15:00:36 <GeKo> if you looked at the thread i am talking about, the poster actually kindly investigated the problem
15:00:39 <arma1> antonela: we have a huge infrastructure of people who are already doing the 'noticing people with an issue, and interpreting it into a proper ticket' process. but we didn't use that group of people as well as we could have, here.
15:00:44 <GeKo> and made suggestions about what is wrong
15:00:54 <irl> metrics meeting is now, karsten gaba let's go to meeting2
15:00:55 <pili> I think this goes back to getting some community team involvement to help out here
15:01:02 <antonela> arma1, why we dont?
15:01:12 <karsten> irl: yes, just wanted to suggest that.
15:01:36 <arma1> antonela: that "why we don't" is a great question to think through.
15:01:37 <pili> irl: karsten gaba sorry for taking over the channel :)
15:01:44 <hiro> GeKo: I tend to disagree on that. The poster actually mixed two different things in the ticket and eventually complained about what many people call "screen real estate"
15:01:50 <irl> no worries, thanks for scheduling it an hour earlier so i could do both meetings
15:02:09 <hiro> and directed the issue to the new design.
15:02:28 <hiro> I think we should take a step back and ask a few questions here:
15:02:45 <hiro> 1. We didn't support any device before because the website wasn't responsive
15:03:10 <hiro> So now we actually have something that allows people on mobile to read content on our website
15:03:24 <antonela> THAT
15:03:37 <pili> arma1: antonela so are we suggesting that we need to get the tor-internal community involved earlier to let them know that these changes are happening and that we will need their help dealing with feedback?
15:03:42 <hiro> 2. What are people complaining?
15:04:48 <hiro> This poster send a request about media queries that wasn't accurate... he was complaining in fact about the height of the top bar.
15:04:56 <pili> hiro: I agree, I think it helps to put things into context for people
15:05:09 <hiro> there are many emails like that on tor-talk
15:05:10 <pili> but it's hard to get the time to do so when we're firefighting
15:05:36 <hiro> but we also have to consider what are good practices nowadays for web dev and for design
15:05:50 <hiro> our "core community" is not into those practices
15:05:55 <hiro> but tpo doesn't only serve them
15:06:44 <arma1> pili: something slightly different. first, it's not about knowing that we need them, it's about knowing how they should best help. in this case, we had a bunch of people who found what might have been bugs, but they weren't sure whether they were bugs, because they didn't know what was the intended functionality.
15:06:44 <GeKo> hiro: yeah, sounds good to me. i think we should communicate that
15:06:45 <hiro> and if you live in bash-land or vim or emacs ;) anything that looks a little different from that will always be looked at as if it is wrong or "people don't know what they are doing"
15:07:09 <arma1> pili: and second, it's not just tor-internal, it's all the various folks who want to be helpful. limiting ourselves to telling ourselves in secret leaves many helpful people out.
15:07:37 <hiro> arma1, GeKo: we do not want to do things in secret
15:07:43 <hiro> but there are as many things we can do
15:08:01 <hiro> we have to also consider the cost (in time and people) of doing 1 activity or another
15:08:27 <isabela> hmm
15:08:28 <isabela> i understand that we did communicate how to report bugs
15:08:30 <hiro> my approach in this cases is ignore the lists the first few days
15:08:39 <isabela> but the point here is to understand or to ask a question
15:08:45 <isabela> to know if what you think is a bug is a bug
15:08:47 <hiro> and then go back to everyone at a later point
15:08:53 <GeKo> isabela: yes
15:08:54 <isabela> that i would say the weekly meetings and or the irc channel
15:09:10 <isabela> would have been the easiest way when ppl were under fire
15:09:11 <hiro> but I think that's what we did, isn't it?
15:09:13 <isabela> to get their attention
15:09:18 <isabela> but that said
15:09:33 <hiro> we used irc, talked to people and replied on the tickets
15:09:34 <isabela> anyone can write to the ux-team list or ask that question on the bug itself
15:09:38 <isabela> the ticket itself
15:09:39 <isabela> too
15:10:01 <isabela> we cant predicted all questions, we did directed folks to a way to communicate w/ us and report thigns tho
15:10:48 <isabela> i am not sure how we can present w/ info regarding a question like this upfront without knowing this question would be a question
15:10:48 <isabela> hehe
15:10:48 <hiro> GeKo is my reply on that ticket was brief it wasn't because I didn't care
15:10:48 <isabela> u know what i am saying? :)
15:11:14 <isabela> that is why we presented ways to communicate w/ us
15:12:14 <antonela> we can include a banner, yes for people to back to the previous site and also to open a ticket
15:12:27 <pili> antonela: +1
15:12:40 <hiro> at the same time we should also accept that when there are changes there is criticism
15:12:54 <hiro> especially considering the level of comments we usually get
15:13:01 <emmapeel> i also think it became better when we started gardening the tickets
15:13:02 <isabela> true
15:13:37 <pili> we plan to do a triage on these every 2 weeks btw
15:13:37 <antonela> last triagge just have hiro and antonela names
15:13:38 <stephw> i think a banner might be too much at this point
15:13:49 <stephw> what about a link to the archive site in the footer?
15:13:58 <hiro> and that people are free to raise issues but we shouln't expect to jump on every issue right away
15:14:05 <antonela> even now
15:14:22 <hiro> stephw the site is linked in the top bar documentation goes to the old site
15:14:26 <pili> stephw: for this one it's probably too late, yes, and I would only keep it around for a month or so
15:15:13 <arma1> hiro: but only if you already know that :)
15:15:24 <hiro> there is another point regarding jumping on issues: we need time to analyse the feedback and act on it
15:15:39 <isabela> we can change from documentation to old site
15:15:39 <arma1> (that is, if you already know there is an old site, and that the thing you're looking for might be there)
15:15:41 <stephw> Site Archive
15:17:29 <arma1> ok, we're way over time here
15:17:36 <pili> yup
15:17:37 <pili> I didn't want to cut people off though
15:17:45 <arma1> so let me throw out one more thing: i don't have an answer, but, i wonder if we can make hiro not so much the bottleneck here
15:17:48 <emmapeel> maybe we could have in jenkins some test that after the build checks if a list of links are giving 404... that would make it easier for different stakeholders to make sure links they depend on stay alive
15:17:56 <isabela> pili: thanks for organizing this :) maybe we keep track of the things we marked as we should do for community
15:17:59 <arma1> like, we have ten people who could edit the old site,
15:17:59 <ggus> why we would include a new link to the old website, besides the docs files?
15:18:00 <isabela> and continue to iterate
15:18:28 <pili> yup, I've been adding some items to the pad: 	https://storm.torproject.org/shared/JozR2ypLQhRca6h5ZapFBfIQbnCwLs0UkSDUw4XBgBD
15:18:35 <arma1> and we have...fewer? who can edit the new one. partly because we don't know the format, but partly because there is no structure for how to know
15:18:42 <pili> I will do a second pass on the meeting logs later to add any missing items
15:18:47 <isabela> awesome
15:19:16 <pili> arma1: fwiw the new one should be a lot easier to maintain
15:19:25 <arma1> emmapeel: right, making a big list of urls, and then hitting them all automatically, and making sure you don't get any error, should be doable
15:19:35 <arma1> pili: should we add some people to do that then?
15:19:36 <pili> we can definitely get more people involved
15:19:39 <pili> we have set of guidelines to follow
15:19:41 <arma1> i haven't learned the new format yet
15:19:44 <hiro> arma1: actually emmapeel has been documentinc lektor on the wiki
15:19:46 <pili> not sure if they are documented anywhere yet
15:19:59 <hiro> all the steps
15:19:59 <arma1> but also i don't know whether i should be messing with it
15:20:03 <arma1> and there are probably many people who could help but don't know whether they should
15:20:03 <ggus> lektor is documented in trac
15:20:04 <ggus> we could create a new page
15:20:05 <pili> but we also want to keep the new website simple
15:20:08 <ggus> like new portals
15:20:10 <emmapeel> i started documenting lektor for the support portal but i am afraid it got a bit outdated and it is not general
15:20:13 <pili> and easy to maintain
15:20:21 <pili> so let's keep that in mind when we want to add new pages :)
15:20:23 <emmapeel> i have promised to document it better, more in general etc
15:20:30 <hiro> the idea behind the new format is that people mostly edit the markdown
15:20:38 <ggus> emmapeel: i tested last week in a vm, and updated it ;)
15:20:38 <arma1> seems like "identify bottlenecks" is a key thing for a retrospective. and here is one. :)
15:20:59 <pili> arma1: yup, that's a good one for sure ;)
15:22:00 <emmapeel> ggus: great!
15:22:03 <hiro> arma1: I think in the last few months very few people updated the website
15:22:14 <emmapeel> https://trac.torproject.org/projects/tor/wiki/org/operations/services/support here the instructions
15:22:18 <hiro> I am referring to webwml
15:22:34 <pili> maybe we can have a session on this at the dev meeting? show and tell and learn :)
15:22:54 <hiro> there is supposed to be a session about making people more independent
15:22:56 <pili> how does the new website work, benefits, how can people edit/update
15:23:13 <isabela> arma1: anyone can help code, but i believe that the team working on the sites are following a process and discussing it etc so makes way more sense to join that and help code what is being planed that
15:23:18 <isabela> *there
15:23:28 <hiro> yes
15:23:42 <hiro> we have things like a styleguide for example
15:23:50 <isabela> yes, and wireframes
15:23:51 <arma1> isabela: yep. but that process also means very few people will feel like they should be fixing things.
15:23:58 <isabela> ?
15:24:05 <isabela> how come
15:24:08 <arma1> and that's a tradeoff we should acknowledge, even if it's the choice we chose
15:24:14 <hiro> irl has been using that also for projects that do not use lektor
15:24:47 <irl> the research website is hugo https://github.com/irl/torproject-hugo
15:24:48 <arma1> isabela: because of the work required to count as being involved?
15:25:00 <isabela> people can fix things within that too, i am just saying that would not make a lot of sense for someone to request to merge a bunch of new pages in a different layout etc
15:25:06 <arma1> isabela: "go back in time and be part of those discussions"
15:25:14 <isabela> arma1: if you want to pick a ticket on trac and fix is one thing
15:25:27 <isabela> i am talking about 'mess around w/ the site'
15:25:35 <hiro> arma1 there is work to do in any of the projects we have, why do we want it to be different for the website?
15:25:46 <isabela> submit a patch is just like any other team
15:26:22 <arma1> ok. this is a retrospective. i don't have the answers. so i will stick with "this is a bottleneck we should work to resolve"
15:26:22 <hiro> I think the tradeoff is between spaghetti website and having a system that can be replicated
15:26:55 <arma1> and i guess part of the resolution involves communicating more. but i don't know how best to do that.
15:27:05 <arma1> i feel like many of the bug reporters still don't know whether their reported bug counts as a bug
15:27:07 <GeKo> yeah, i agree
15:27:26 <hiro> arma1, GeKo, there is a channel tor-www we talk there daily
15:27:34 <arma1> like, is it not fixed yet because it's in the queue, and we don't have enough people to fix it, or, is it not being fixed yet because nobody is going to fix it
15:27:36 <pili> arma1: true, but that could also be said for some browser team bugs :)
15:27:53 <isabela> triage is what takes care of that i think
15:27:53 <GeKo> *cough*
15:27:58 <isabela> that said
15:28:12 <arma1> pili: sure! and that is a problem there too.
15:28:12 <isabela> the whole team was in ane vent
15:28:15 <isabela> *an event
15:28:37 <isabela> but, mostly to deal with the bugs is triage. idk, how does other teams do when they have a long backlog of bugs open that are waiting
15:29:00 <hiro> I have been fixing issues in the website to be honest, while also working on the community website that we have to launch
15:29:17 <isabela> i know
15:29:49 <ggus> irl: very nice hugo port of tor styleguide. this is documented in trac, how to build research portal?
15:30:00 <irl> ggus: it's in the readme file
15:30:16 <irl> https://gitweb.torproject.org/research-web.git/tree/README.md?h=staging
15:30:33 <pili> we should really wrap this up though
15:30:42 <pili> we have a number of questions that we should reflect on
15:31:15 <pili> we will also try to move the website meetings to irc so more people can be aware of what is going on and get involved
15:31:38 <isabela> +1
15:31:38 <pili> and we will try to implement some of these take aways for the next launch
15:31:42 <pili> any last comments/ideas? :)
15:31:55 <pili> (feel free to add any I have missed in the pad also: https://storm.torproject.org/shared/JozR2ypLQhRca6h5ZapFBfIQbnCwLs0UkSDUw4XBgBD )
15:32:03 <GeKo> the take aways look good to me
15:32:08 <GeKo> nice outcome
15:32:20 <arma1> thanks for helping to think things through!
15:32:41 <GeKo> +1
15:33:03 <gman999> we can run some 'linkchecker' type scripts
15:33:10 <gman999> to find broken links
15:33:19 <gman999> something to keep in mind
15:33:29 <arma1> yeah, it seems like having a big list of all the links that we think work might be smart for the next site launch
15:33:37 <arma1> because then as soon as you roll out the new one,
15:33:42 <arma1> you press the button and find the surprises
15:33:51 <gman999> not a list as much as a crawler
15:34:26 <arma1> hm. those are two separate ideas.
15:34:34 <arma1> a crawler will find whether your current site has broken links in it
15:34:47 <arma1> and the big list will find out whether your expected urls will work
15:34:52 <gman999> right.  that was my point.
15:34:52 <gman999> right.
15:35:47 <pili> ok
15:35:52 <pili> I'm going to close this meeting
15:35:58 <pili> and people can keep on discussing ;)
15:36:06 <emmapeel> #29860 FWIW
15:36:09 <pili> thanks for the feedback everyone
15:36:17 <pili> I hope people found it helpful
15:36:22 <pili> #endmeeting