14:01:35 #startmeeting website launch retrospective 04/11 14:01:35 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:01:37 that didn't work... 14:01:41 there we go, a bit slow 14:02:31 hola! 14:02:48 before we get started, I would like to share the prime directive: http://retrospectivewiki.org/index.php?title=The_Prime_Directive 14:03:00 so we can bear this in mind during the retrospective :) 14:03:35 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 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 during this part we can talk about what happened, what went well and what we can learn for next time 14:04:49 yeah i cannot read this directive neither :S 14:05:26 "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 part 2 will be discussing what we will do differently for the community portal 14:05:49 does that work for people? 14:05:50 thx 14:06:50 (part 3 will be discussing how the community portal launch is going if we have time to discuss) 14:07:36 anyone want to start? otherwise I can start listing what happened :) 14:08:31 ok, I'll go then :) 14:08:32 sounds like you should start :) 14:09:18 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 regularly = about once a week 14:10:28 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 this was done in early february 14:11:00 we were mainly looking for broken link reports as well as visual bugs 14:11:46 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 this process was finalised mid-late February 14:12:32 from then on antonela and hiro started working on fixing those reported issues ready for our launch 14:12:54 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 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 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 I feel like a lawyer :D 14:15:22 :D 14:15:24 (is good tho :) 14:15:48 we had a few issues with the jenkins instance on the day of the silent launch 14:17:05 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 it's not exactly the website build 14:18:02 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 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 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 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 :) 14:20:34 anyway, I think that's all I had to share for now, I would like to open this up to others 14:22:29 any feedback or comments from anyone? :) 14:22:30 (seems like a lot of people are being quiet to let others talk. that's what i'm doing at least.) 14:22:46 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 agreed 14:23:25 emmapeel: does that imply maybe a longer quiet-launch period? 14:23:49 more staging time? or more time live without social media noise? 14:23:52 on the theory that the press announcement wants to happen when there are some languages 14:23:53 arma1: no... just maybe launch in english and spanish and then in 3 days having more langs 14:24:00 yeah 14:24:01 just launch 14:24:09 and use the buzz to get folks engaged :) 14:24:32 sounds like a useful step 14:25:24 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 great happy to share that, keep me updated 14:26:09 (can we keep these useful new steps listed on a pad?) 14:26:13 antonela: 'more time live without social media noise' was what i had meant 14:26:27 isabela: let me create one quickly 14:26:49 great, i agreed 14:26:51 well we cannot control all of social media 14:27:06 so people started talking about it before we do 14:27:17 its fine, we cannot control it 14:27:18 so having that be as short as possible is best from the comms side 14:27:37 but we need time to fix this kind of things that only happened in live domains 14:27:52 yes i understand, i am just telling what happens from this side 14:27:56 why do things only happen in the live domain? 14:28:02 that seems like we've got a bad staging env 14:28:11 https://storm.torproject.org/shared/JozR2ypLQhRca6h5ZapFBfIQbnCwLs0UkSDUw4XBgBD 14:28:41 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 we have things that are around that we didn't think of 14:29:23 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 maybe i do not understand 14:29:44 yes it's the other way around 14:29:47 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 yes, of course, i'm wondering if one of the lessons is that we need a better staging setup 14:30:06 let's keep those lessons somewhere written 14:30:07 well, first time in a while :) 14:30:16 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 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 how those map to what we are changing 14:30:35 ggus: +1 14:30:43 yes :) (first time in many years) 14:31:07 did we have a full map of old urls to new urls with redirects? 14:31:12 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 someone told us that you can help us on it irl 14:31:27 and we have this mapping 14:31:33 but some things slips 14:31:48 also because of all the redirects we had on our old .htaccess 14:32:00 yeah, it seems like whatever the process was for making that mapping beforehand, or shortly after, could be improved 14:32:12 and because some pages (like all the different donate pages we have...) redirect to even older things 14:32:35 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 well 14:32:56 uhm... not really... 14:33:01 some content will be replaced in those portals 14:33:10 stuff that is on 2019.www 14:33:20 also some content is being updated giving that we have another website 14:33:46 https://docs.google.com/spreadsheets/d/1hoceLEYevlxbVu5z5g7mdCPoBuhv6e0xJ3bRPEYWv4A/edit#gid=0 14:33:47 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 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 we had a few issues 14:34:07 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 is anyone using webstats to see what urls people are hitting often to prioritise those for redirects? 14:34:19 and a little bit of broken links for a few hours 14:34:33 irl I am checking the apache logs to be honest 14:34:43 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 i heard folks are using apache 404 logs too, to catch things we missed 14:34:50 but i only did it a while after 14:35:01 irl, nope, that is one of the main reasons i shared fathom yesterday https://github.com/usefathom/fathom 14:35:03 you shouldn't need to log in to the host, our web logs are in collector 14:35:08 they are public 14:35:25 irl: how long is the delay before they get to collector? 14:35:30 a few days 14:35:41 that seems not best, for this situation :) 14:35:53 right, but maybe a takeaway here is that we need to improve on that 14:35:55 for metrics 14:36:01 i reacted to users on irc, but i have no access to the logs 14:36:06 (that i know of) 14:36:27 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 arma1: most of the 404 were predicted 14:37:38 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 so I noticed this and fixed the script 14:38:04 but this didn't sync right away in the building job 14:38:31 and it did about 4/6 hours later, when I went to pull the diff in all the jenkins slaves 14:40:01 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 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 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 jenkins synced around 10pm my time 14:40:53 then I went to bed and fixed the rest in the morning 14:40:56 sysrqb: yes, this is certainly true for external documentation and web pages and so on 14:41:03 that also why they staid for a while 14:41:14 *stayed 14:41:17 i believe that a 404 can be cached, which can be a problem 14:41:32 irl: cached where? 14:41:47 it's a "permanent error" so it's expected that if a thing is 404 then it stays 404 14:41:57 I think we had 404 for like less than 24 hours. 14:42:00 so either delete something from a search index or cache in the browser or anywhere that caching occurs 14:42:11 we*sel decreased the cache time on the webserver, i believe 14:42:19 hah 14:42:31 yes weasel did while we were in this "silent launch" 14:42:36 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 that should be entirely doable 14:43:05 sounds like a nice automated test :) 14:43:08 boklm: i really like the idea of automation here 14:43:31 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 now, *who* has the cycles for this? :) 14:44:11 i don't think it's fair to put all of this on hiro 14:44:12 sysrqb: that's another issue. website ops and dev is only me. 14:44:17 right 14:44:20 i could run our webstats through awstats on an ec2 thing 14:44:51 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 also, i don't think it was said yet, but thanks hiro, antonela and everyone who worked on this 14:45:34 +1 14:45:51 yes! great point. overall we succeeded. let us not forget that. :) 14:45:52 +1 14:45:53 +1 14:46:14 the assets pipeline is different from the new website... if we care about images I can redirect all of them 14:46:21 to 2019 14:46:49 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 hiro: what is the process for making that sort of decision? 14:47:03 hiro: like, who is supposed to decide the answer to 'if we care about' 14:47:24 angry people on channels or mailing lists is not the answer, for sure 14:47:25 I had a mapping spreadsheet of pages and content and worked with that 14:47:31 yes 14:47:36 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 also we have a little over 10 minutes :) 14:47:42 arma1: i tried to organized that 14:47:45 and i pasted it some lines above 14:47:57 i did not think of images but we did mapped the urls and organized them in categories 14:48:16 so we can track what will stay as it is after all the new portals are done etc 14:48:33 that's exactly the point. we can't eliminate the pain giving the complexity of the information we have 14:48:55 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 letme get the url for the spreadsheeet 14:48:58 there are things that we can't anticipate because we do not know where and what links to some bits 14:49:15 isabela https://docs.google.com/spreadsheets/d/1hoceLEYevlxbVu5z5g7mdCPoBuhv6e0xJ3bRPEYWv4A/edit#gid=0 14:49:21 (this was step zero, done like 2years ago or something 14:49:32 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 and that made the loop between 'bug noticed' and 'bug fixed' longer than it needed to be 14:50:06 that is the point 14:50:09 who should do it? 14:50:15 hmm 14:50:20 the loop can't be made much shorter because in the end the bug fixed point is always me 14:50:23 i am confuse here 14:50:24 who should do what. because there are several 'it's here 14:50:30 and I can process as many bugs per hour 14:50:50 who should reply the lists, extract the issues, open tickets, read social media, open tickets? 14:50:53 that's a different issue 14:51:04 from the one arma brought up 14:51:18 to give an example 14:51:27 take #29934 14:51:40 i read that on tor-relays 14:51:47 i am confuse to what is being asked 14:51:49 and it seemed pretty reasonable 14:51:54 so i filed a ticket 14:52:03 but is it a ticket worth at all? 14:52:06 i don't know 14:52:11 everybody is trying to reach it and cannt open, but i think is related with the download pagfe 14:52:27 oh css one 14:52:39 it's about the css media rules mixup 14:52:39 "#29934: CSS media rule mixes all types of screens together" 14:52:46 hmm 14:52:59 the answer on the ticket was "it's bootstrap" 14:53:03 seems like that person doesn't have any idea how bootstrap works 14:53:18 regarding this question 14:53:26 well, that's not important 14:53:31 how bootstrap works 14:53:48 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 the important thing is whether our website is accessible and working well 14:53:54 so folks can see what has been reported 14:54:01 https://getbootstrap.com/ 14:54:32 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 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 GeKo in a way bootstrap makes our website more accessible and working with different devices that the old one 14:55:08 and we did asked maggie to do that too 14:55:15 on ggus' point, the call for comments should be made early publicly 14:55:16 keep an eye on reactions etc 14:55:17 no? 14:55:36 isabela: actually, not for the website 14:55:37 so there's something to point to for those who want to be involved in the process. 14:55:37 we did that for the browser releases 14:55:59 yes, but i don't know if she got my email 14:56:06 did we ever have a banner on the website to explain the new website and how to provide feedback? 14:56:07 ah, ok 14:56:16 irl: great question. i think no 14:56:20 no, we should 14:56:22 ggus: got it 14:56:35 ok 14:56:42 so we should list on the pad that 14:56:43 and also a link to back to the previous website for people who is uncomfortable with changes 14:56:50 because this is what maggie does :) she is our user support 14:56:55 she collects feedbacks :) 14:57:01 even just another comment on tor-talk 14:57:21 the toxic thing happened in tor-talk was surprising for me 14:57:28 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 even twitter nor reddit was that hard 14:57:59 arma1: we explained how to report on blog post and on the email to internal (asking ppl to test stuff) 14:58:14 yes, both times 14:58:19 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 right now it looks as if we don't do our job well 14:59:05 GeKo: I think we are afraid of people judgind us 14:59:17 who is "we"? 14:59:26 I am talking generally 14:59:39 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 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 antonela: i don't think so 15:00:36 if you looked at the thread i am talking about, the poster actually kindly investigated the problem 15:00:39 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 and made suggestions about what is wrong 15:00:54 metrics meeting is now, karsten gaba let's go to meeting2 15:00:55 I think this goes back to getting some community team involvement to help out here 15:01:02 arma1, why we dont? 15:01:12 irl: yes, just wanted to suggest that. 15:01:36 antonela: that "why we don't" is a great question to think through. 15:01:37 irl: karsten gaba sorry for taking over the channel :) 15:01:44 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 no worries, thanks for scheduling it an hour earlier so i could do both meetings 15:02:09 and directed the issue to the new design. 15:02:28 I think we should take a step back and ask a few questions here: 15:02:45 1. We didn't support any device before because the website wasn't responsive 15:03:10 So now we actually have something that allows people on mobile to read content on our website 15:03:24 THAT 15:03:37 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 2. What are people complaining? 15:04:48 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 hiro: I agree, I think it helps to put things into context for people 15:05:09 there are many emails like that on tor-talk 15:05:10 but it's hard to get the time to do so when we're firefighting 15:05:36 but we also have to consider what are good practices nowadays for web dev and for design 15:05:50 our "core community" is not into those practices 15:05:55 but tpo doesn't only serve them 15:06:44 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 hiro: yeah, sounds good to me. i think we should communicate that 15:06:45 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 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 arma1, GeKo: we do not want to do things in secret 15:07:43 but there are as many things we can do 15:08:01 we have to also consider the cost (in time and people) of doing 1 activity or another 15:08:27 hmm 15:08:28 i understand that we did communicate how to report bugs 15:08:30 my approach in this cases is ignore the lists the first few days 15:08:39 but the point here is to understand or to ask a question 15:08:45 to know if what you think is a bug is a bug 15:08:47 and then go back to everyone at a later point 15:08:53 isabela: yes 15:08:54 that i would say the weekly meetings and or the irc channel 15:09:10 would have been the easiest way when ppl were under fire 15:09:11 but I think that's what we did, isn't it? 15:09:13 to get their attention 15:09:18 but that said 15:09:33 we used irc, talked to people and replied on the tickets 15:09:34 anyone can write to the ux-team list or ask that question on the bug itself 15:09:38 the ticket itself 15:09:39 too 15:10:01 we cant predicted all questions, we did directed folks to a way to communicate w/ us and report thigns tho 15:10:48 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 hehe 15:10:48 GeKo is my reply on that ticket was brief it wasn't because I didn't care 15:10:48 u know what i am saying? :) 15:11:14 that is why we presented ways to communicate w/ us 15:12:14 we can include a banner, yes for people to back to the previous site and also to open a ticket 15:12:27 antonela: +1 15:12:40 at the same time we should also accept that when there are changes there is criticism 15:12:54 especially considering the level of comments we usually get 15:13:01 i also think it became better when we started gardening the tickets 15:13:02 true 15:13:37 we plan to do a triage on these every 2 weeks btw 15:13:37 last triagge just have hiro and antonela names 15:13:38 i think a banner might be too much at this point 15:13:49 what about a link to the archive site in the footer? 15:13:58 and that people are free to raise issues but we shouln't expect to jump on every issue right away 15:14:05 even now 15:14:22 stephw the site is linked in the top bar documentation goes to the old site 15:14:26 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 hiro: but only if you already know that :) 15:15:24 there is another point regarding jumping on issues: we need time to analyse the feedback and act on it 15:15:39 we can change from documentation to old site 15:15:39 (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 Site Archive 15:17:29 ok, we're way over time here 15:17:36 yup 15:17:37 I didn't want to cut people off though 15:17:45 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 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 pili: thanks for organizing this :) maybe we keep track of the things we marked as we should do for community 15:17:59 like, we have ten people who could edit the old site, 15:17:59 why we would include a new link to the old website, besides the docs files? 15:18:00 and continue to iterate 15:18:28 yup, I've been adding some items to the pad: https://storm.torproject.org/shared/JozR2ypLQhRca6h5ZapFBfIQbnCwLs0UkSDUw4XBgBD 15:18:35 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 I will do a second pass on the meeting logs later to add any missing items 15:18:47 awesome 15:19:16 arma1: fwiw the new one should be a lot easier to maintain 15:19:25 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 pili: should we add some people to do that then? 15:19:36 we can definitely get more people involved 15:19:39 we have set of guidelines to follow 15:19:41 i haven't learned the new format yet 15:19:44 arma1: actually emmapeel has been documentinc lektor on the wiki 15:19:46 not sure if they are documented anywhere yet 15:19:59 all the steps 15:19:59 but also i don't know whether i should be messing with it 15:20:03 and there are probably many people who could help but don't know whether they should 15:20:03 lektor is documented in trac 15:20:04 we could create a new page 15:20:05 but we also want to keep the new website simple 15:20:08 like new portals 15:20:10 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 and easy to maintain 15:20:21 so let's keep that in mind when we want to add new pages :) 15:20:23 i have promised to document it better, more in general etc 15:20:30 the idea behind the new format is that people mostly edit the markdown 15:20:38 emmapeel: i tested last week in a vm, and updated it ;) 15:20:38 seems like "identify bottlenecks" is a key thing for a retrospective. and here is one. :) 15:20:59 arma1: yup, that's a good one for sure ;) 15:22:00 ggus: great! 15:22:03 arma1: I think in the last few months very few people updated the website 15:22:14 https://trac.torproject.org/projects/tor/wiki/org/operations/services/support here the instructions 15:22:18 I am referring to webwml 15:22:34 maybe we can have a session on this at the dev meeting? show and tell and learn :) 15:22:54 there is supposed to be a session about making people more independent 15:22:56 how does the new website work, benefits, how can people edit/update 15:23:13 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 *there 15:23:28 yes 15:23:42 we have things like a styleguide for example 15:23:50 yes, and wireframes 15:23:51 isabela: yep. but that process also means very few people will feel like they should be fixing things. 15:23:58 ? 15:24:05 how come 15:24:08 and that's a tradeoff we should acknowledge, even if it's the choice we chose 15:24:14 irl has been using that also for projects that do not use lektor 15:24:47 the research website is hugo https://github.com/irl/torproject-hugo 15:24:48 isabela: because of the work required to count as being involved? 15:25:00 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 isabela: "go back in time and be part of those discussions" 15:25:14 arma1: if you want to pick a ticket on trac and fix is one thing 15:25:27 i am talking about 'mess around w/ the site' 15:25:35 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 submit a patch is just like any other team 15:26:22 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 I think the tradeoff is between spaghetti website and having a system that can be replicated 15:26:55 and i guess part of the resolution involves communicating more. but i don't know how best to do that. 15:27:05 i feel like many of the bug reporters still don't know whether their reported bug counts as a bug 15:27:07 yeah, i agree 15:27:26 arma1, GeKo, there is a channel tor-www we talk there daily 15:27:34 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 arma1: true, but that could also be said for some browser team bugs :) 15:27:53 triage is what takes care of that i think 15:27:53 *cough* 15:27:58 that said 15:28:12 pili: sure! and that is a problem there too. 15:28:12 the whole team was in ane vent 15:28:15 *an event 15:28:37 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 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 i know 15:29:49 irl: very nice hugo port of tor styleguide. this is documented in trac, how to build research portal? 15:30:00 ggus: it's in the readme file 15:30:16 https://gitweb.torproject.org/research-web.git/tree/README.md?h=staging 15:30:33 we should really wrap this up though 15:30:42 we have a number of questions that we should reflect on 15:31:15 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 +1 15:31:38 and we will try to implement some of these take aways for the next launch 15:31:42 any last comments/ideas? :) 15:31:55 (feel free to add any I have missed in the pad also: https://storm.torproject.org/shared/JozR2ypLQhRca6h5ZapFBfIQbnCwLs0UkSDUw4XBgBD ) 15:32:03 the take aways look good to me 15:32:08 nice outcome 15:32:20 thanks for helping to think things through! 15:32:41 +1 15:33:03 we can run some 'linkchecker' type scripts 15:33:10 to find broken links 15:33:19 something to keep in mind 15:33:29 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 because then as soon as you roll out the new one, 15:33:42 you press the button and find the surprises 15:33:51 not a list as much as a crawler 15:34:26 hm. those are two separate ideas. 15:34:34 a crawler will find whether your current site has broken links in it 15:34:47 and the big list will find out whether your expected urls will work 15:34:52 right. that was my point. 15:34:52 right. 15:35:47 ok 15:35:52 I'm going to close this meeting 15:35:58 and people can keep on discussing ;) 15:36:06 #29860 FWIW 15:36:09 thanks for the feedback everyone 15:36:17 I hope people found it helpful 15:36:22 #endmeeting