16:02:37 <pili> #startmeeting websites 09/04
16:02:37 <MeetBot> Meeting started Wed Sep  4 16:02:37 2019 UTC.  The chair is pili. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:37 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:03:14 <pili> can people update the pad with updates and discussion: https://storm.torproject.org/shared/bWNyJ1JRq9mUZiRsCzlOA8k_R0VccQf4Ys-FuiFsfB8
16:03:15 <pili> while the current meeting wraps up... :)
16:04:57 <ggus> ok
16:05:23 <emmapeel> o/
16:06:25 <antonela> hello
16:06:28 * antonela looking at the pad
16:11:14 <pili> sorry, still on the other meeting :/
16:11:18 <pili> can you go ahead and start sharing updates :)
16:11:45 <pili> we won't have hiro today
16:11:48 <pili> do we have stephw ?
16:12:03 <stephw> hi!
16:13:56 <pili> no one want to share any updates? :)
16:14:14 <pili> ok
16:14:21 <pili> I'm 100% here now
16:14:24 <pili> sorry about that
16:14:33 <ggus> i'm updating the pad
16:15:14 <emmapeel> sorry got lost
16:15:15 <pili> ggus: you have a lot on there already! :D
16:15:27 <emmapeel> not many updates, enjoying the hackathon
16:15:49 <pili> that's good :)
16:16:10 <pili> well, if no one has any updates maybe we can move forward with the discussion?
16:16:11 <ggus> the relay operation section is almost done. i think it's only missing 3 things
16:16:28 <pili> that's great ggus ! A huge amount of content there!
16:16:31 <ggus> who can review?
16:16:38 <ggus> beside us
16:16:54 <pili> first of all I think it's too much content for stephw to review...
16:17:14 <pili> and there are other smaller sections that are probably more important
16:17:29 <pili> this is all content that was on the wiki, right?
16:17:32 <emmapeel> we have phw taking care of that section a lot too
16:17:33 <ggus> i was thinking to reach out network-health
16:17:36 <ggus> pili: right
16:17:46 <pili> if so, do we need to review it? as in, shouldn't it have been peer-reviewed already?
16:17:55 <pili> as in, people updating it when they saw it was wrong?
16:18:08 <pili> do we want to review wording or content also?
16:18:53 <emmapeel> i think we have to make sure stephw can use the edit button and for sure some small style corrrections will appear
16:19:19 <pili> so maybe that takes me to my discussion point about the workflow review
16:19:33 <pili> because I think we now have all the pieces in place to be able to do this properly :)
16:19:52 <pili> maybe we can discuss my workflow proposal first?
16:19:59 <pili> any tweaks?
16:20:16 <antonela> i like your workflow proposal pili
16:20:38 <pili> we probably need to try it also and see if it works
16:20:56 <ggus> i don't remember this proposal
16:21:03 <antonela> does stephw has a dip account in place already?
16:21:04 <antonela> ggus, is in the pad
16:21:13 <pili> :D
16:21:15 <stephw> yes i do
16:21:21 <pili> hmm, maybe I can document this workflow on the community portal wiki...  and people can update as they try it out and find out what works/doesn't work
16:21:34 <antonela> stephw: awesome 😎
16:22:54 <emmapeel> regarding that workflow i dont want to be checking if each page has been translated or not. we have only one big file for the translation. i will send to translate and once in a while i will look and see if there are translations ready
16:23:12 <emmapeel> it is not that i send each file to translate separately and i receive them translated
16:23:16 <pili> ok
16:23:33 <emmapeel> i will send the whole community portal to translate at once
16:23:53 <ggus> for relay technical setup section, i'd like to loop with someone from network health
16:24:04 <pili> ok, so we're not going to wait for translation before pushing to master then
16:24:09 <ggus> ideally people would use those pages to reach out relay operators with old tor
16:24:26 <pili> I guess we need to decide at which point you send the community portal for translation
16:25:13 <emmapeel> pili: yes, that would be a decision to take. i said many strings were still not ready and i need them all ready to send... but yeah when is the website in production?
16:25:14 <pili> and what happens when there are updates, e.g new pages added to the community portal
16:25:37 <emmapeel> right now, i regenerate the translation file and upload by hand a new one to transifex
16:25:48 <emmapeel> so the new strings appear untranslated and the old ones stay
16:25:57 <pili> ok
16:26:14 <emmapeel> atm changes on the content file do not automatically trigger changes in transifex in any lektor
16:27:17 <pili> ok, let me tag the tickets that need to be ready before we can say the website is ready for production
16:27:28 <pili> as a milestone in gitlab
16:27:32 <pili> we should prioritise though
16:27:43 <pili> *those
16:27:58 <clash> Is it possible to trigger transifex builds by webhook?
16:28:01 <pili> and when the milestone is complete we should send for translation
16:28:10 <clash> Then every push to GitHub will automatically trigger a build
16:28:13 <emmapeel> i want to prevent transaltors from translating strings that are going to dissapear afterwards. or for example strings with FIXME, etc
16:28:41 <emmapeel> they get upset about that
16:29:09 <emmapeel> anyway we still have a lot of stuff to translate if they want :D
16:29:33 <pili> yeah, we don't want to upset translators :)
16:29:33 <emmapeel> the only 100% lang is Turkish atm
16:30:08 <pili> ok, so I'll do a review of outstanding tickets, tag them with the milestone and we prioritize those for completion, ideally by end of September
16:30:17 <pili> then they can't be sent for localization
16:30:47 <pili> any items that we need stephw to review should be moved to the needs review column: https://dip.torproject.org/web/community/-/boards
16:31:16 <pili> and when stephw is done with review and revisions, we push to master and close the ticket
16:31:31 <pili> then when the production milestone is done we send for translation
16:31:36 <pili> any questions? comments?
16:31:43 <antonela> if this workflow goes ok, we can automatize that step i think
16:31:55 <antonela> 🤖
16:32:02 <emmapeel> i like it more like that, yes. i think translations are slow and we should focus on a good longterm support for translations
16:32:17 <pili> ok
16:32:23 <emmapeel> but the stress of releasing with all translations did not work well with past websites
16:32:30 <pili> right
16:32:31 <emmapeel> the nicer reviewers may be busy, etc...
16:33:13 <pili> ok, any other comments on workflow? shall we move on to the next item? :)
16:33:48 <emmapeel> i had some issues when finally yesterday tried the recommended workflow
16:34:11 <emmapeel> as ggus imported a repo in dip, with the url from torgit.
16:35:06 <emmapeel> this didnt worked very well because then the branc will not create the pull request against i.e. https://dip.torproject.org/web/community.git but against https://dip.torproject.org/ggus/community.git
16:35:14 <pili> is this the one that hiro added to the gitlab wiki?
16:35:15 <pili> can you share the link so we're all on the same page?
16:35:18 <pili> right, I had that issue
16:35:29 <pili> I think you can change that though, no? with some dropdown?
16:35:48 <emmapeel> i would like to change the recommended workflow then
16:36:24 * emmapeel looks for link
16:37:01 <emmapeel> https://dip.torproject.org/web/tpo/wikis/Git-flow-and-merge-requests
16:37:14 <pili> thanks emmapeel ! :)
16:37:55 <emmapeel> i liked the PRs in github because it is easier to review the diffs against the current version of the repo, but this does not work the same if you improt from url
16:38:48 <emmapeel> is like you cannot compare to the branches on https://dip.torproject.org/web/tpo ir you import from url
16:39:13 <pili> ok, so you are suggesting not to import from gitweb into dip for your own personal repo?
16:39:21 <pili> and instead forking the gitlab repo?
16:40:37 <emmapeel> yes
16:41:24 <emmapeel> which is what you get suggested when you click on the edit button, have an account in dip, and have no repo of your own
16:41:25 <pili> wfm, the only issue I've had with that in the past when working locally is that I need to maintain a bunch of remotes
16:41:48 <antonela> same, but i didnt find any other workaround
16:42:14 <pili> as in, my "origin" remote is gitlab when really I want gitweb to be my origin
16:42:21 <pili> it's fine but it means some git juggling
16:42:23 <emmapeel> yeah lotsa remotes but that is FLOSS
16:42:33 <pili> ok
16:42:45 <emmapeel> i like all this funny remotes also
16:43:00 <emmapeel> bunnyapocalypse, rotationmatrix...
16:43:03 <emmapeel> is like diceware
16:43:06 <antonela> hahaha
16:43:13 <pili> hehe
16:44:21 <pili> I think as long as your local workflow using git works for you, that's fine, as long as we're all on the same page when it comes to getting a review
16:44:40 <pili> as in, stephw needs to be able to follow the same process regardless of who has submitted the PR
16:45:03 <emmapeel> yeah, i would like to go with stephw through a whole 'i want to fix this' cycle
16:45:14 <pili> so she needs to know how to make revisions to the content people submit
16:45:36 <pili> what's the best way to do this? pick an easy ticket and work through it from start to finish?
16:45:45 <pili> e.g do a 1h session of this
16:46:03 <emmapeel> to make revisions to the content people submit?
16:46:14 <stephw> that’d be great. i wont be able to this week, but we could sched in the next 1-2weeks
16:46:30 <pili> emmapeel: yup
16:46:53 <pili> can everyone here push to gitweb staging btw?
16:47:00 <emmapeel> she should be able to run her local install, add a remote, checkout the branch and browse in localhost, or
16:47:26 <emmapeel> pushign to staging the changes could help yes
16:47:53 <emmapeel> merge the branch on staging and push
16:49:15 <pili> what does stephw review then? is there a merge request to master then?
16:49:19 <pili> or does she review a commit?
16:49:26 <pili> or a set of commits?
16:49:47 <emmapeel> i dont understand. it depends on the way 'the people submits content'
16:50:58 <emmapeel> at the moment we have been working in the community portal in master and the reviewes were in master
16:51:13 <pili> well, that's what we need to decide for the workflow
16:51:18 <emmapeel> sometimes in staging
16:51:28 <emmapeel> now we have develop too
16:51:37 <emmapeel> maybe we could use develop to go crazy
16:51:40 <pili> we probably want to be strict and decide on either staging or develop
16:51:50 <pili> for reviewing changes
16:53:13 <pili> ok, let's say staging
16:53:14 <pili> gitweb staging
16:53:21 <pili> as long as everyone here has push access there?
16:54:05 <pili> that's what I have on the workflow on the pad anyway :)
16:54:10 <emmapeel> i dont know about access
16:54:12 <pili> does that make sense to people?
16:54:19 <pili> I think we all should
16:54:38 <pili> let's try this out with stephw next week
16:54:49 <pili> I'll be afk monday - thursday though
16:55:14 <pili> maybe we can re-schedule this meeting for friday
16:55:15 <pili> shall we move on, we have 5 minutes left... :.
16:55:16 <pili> :/
16:56:52 <emmapeel> im groot
16:56:57 <antonela> good here
16:57:13 <pili> ok
16:57:15 <pili> next item? :)
16:57:20 <pili> not sure who added that one :)
16:57:31 <pili> we can probably make that the last one (my other 2 can wait)
16:58:10 <pili> the one about https://dip.torproject.org/web/tpo/issues/2
16:58:19 <pili> maybe it was ggus ?
16:59:11 <ggus> i think we don't have time
16:59:16 <ggus> so i commented on the ticket
16:59:19 <pili> ok :)
16:59:42 <pili> maybe we can continue on #tor-www
16:59:51 <pili> I need to go make dinner though :D
16:59:56 <pili> let's end the meeting here anyway
16:59:59 <pili> #endmeeting