17:00:04 <hellais> #startmeeting 2016-05-02 OONI weekly dev gathering
17:00:04 <MeetBot> Meeting started Mon May  2 17:00:04 2016 UTC.  The chair is hellais. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:04 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:00:07 <hellais> here we go
17:00:15 <hellais> greetings
17:00:34 * willscott waves
17:00:54 <catfish99> #info
17:01:00 <landers> here
17:01:11 <sbs> here
17:01:21 <anadahz> here
17:01:32 <catfish99> #info venezuela study/report
17:01:38 <agrabeli> hi
17:02:41 <hellais> excellent so let's try to keep today's report backs nice and tight. Since some of you have already circulated them it should just be a trivial copy paste job.
17:04:12 <hellais> What I did last week (2016-04-25)
17:04:13 <hellais> ==========================
17:04:13 <hellais> * Work on making a new release for ooniprobe and oonibackend
17:04:13 <hellais> * Work on debugging deployment of oonibackend on MLAB
17:04:13 <hellais> What I plan to do this week (2016-05-02)
17:04:14 <hellais> ===============================
17:04:17 <hellais> * Review the SSL cert validation branch based on feedback from Simone
17:04:20 <hellais> * Review the PR of Lorenzo on measurement-kit-ios
17:04:22 <hellais> * Work on the web_connectivity test branch
17:05:50 <landers> ...(timeout?) nothing new here; no new work on the https backend endpoint, but feel free to bug me about it. EOF
17:06:10 <willscott> I'm in the process of getting satellite in shape for usenix ATC. I expect that will transition into coordinating with anadahz on getting those reports into unified storage with ooni. EOF
17:06:59 <sbs> # What I did last week (2016-04-25)
17:06:59 <sbs> 1. MK: merge Antonio Langiu PRs (GeoIP, LibreSSL, build system)
17:06:59 <sbs> 2. MK-android: help Lorenzo with updating the JNI repository and with
17:06:59 <sbs> rolling out the first version of the Android app
17:06:59 <sbs> 3. MK: review Arturo's PR on SSL certificates validation
17:07:02 <sbs> 4. MK: finish now-working NDT prototype
17:07:04 <sbs> # What I plan to do this week (2016-05-02)
17:07:07 <sbs> 1. MK: continue review of Arturo's PR on SSL certificates validation and
17:07:10 <sbs> possibly review other PRs
17:07:12 <sbs> 2. MK: move NDT prototype to ready for review state
17:07:14 <sbs> 3. MK-android: discuss with Lorenzo and Arturo about true async tests in
17:07:17 <sbs> the JNI environment
17:07:20 <sbs> EOF
17:08:45 <anadahz> Worked on releasing ooni-backend and ooni-probe, Upgrade ooni-backend cannonical bouncer and collector, Furthert developing/testing OONI infrastructure deployments. --EOF
17:09:03 <agrabeli> Last week I created a detailed workplan for myself re OTF deliverables and I reached out to potential OONI partners. Today I wrote some "informed consent" documentation, mapped out the feedback that we received from Harvard CyberLaw Clinic, updated OONI's license (minor edit) and update the legal section of OONI's current github informed consent policy (you can view the pull request here: https://github.com
17:09:09 <agrabeli> /TheTorProject/ooni-spec/pull/55/commits/e8cacd91db981f05ef026c7beed67c0561a83dfa).
17:09:14 <hellais> landers: it would actually be ideal if we could get that completed by the end of this week, since it's blocking on having support for reporting to OONI collectors in MK. Do you think that's doable?
17:10:49 <landers> hellais: yep yep; will do
17:10:59 <hellais> landers: cool
17:11:06 <hellais> ok I think we can now move into the items on the agenda
17:12:00 <hellais> #topic limiting the usage of ooniprobe in at risk countries
17:12:23 <sbs> hellais: what do you exactly mean with limiting?
17:12:36 <agrabeli> Over the next days I'll be: (1) writing a privacy policy for OONI, (2) writing relevant "informed consent" documentation for Harvard Cyberlaw Clinic, (3) Contacting the OTF Legal Lab with the aforementioned documentation_
17:12:41 <agrabeli> and continuing discussions on advice for the creation of a robust
17:12:47 <agrabeli> "informed consent" policy/procedure
17:13:25 <agrabeli> (4) Reviewing the Citizen Lab's proposed category codes for test lists EOF.
17:14:45 <agrabeli> sbs: the Harvard Cyberlaw Clinic have raised concerns in regards to OONI'S data collection models
17:15:35 <sbs> agrabeli: okay, so limiting means preventing them from running?
17:15:47 <agrabeli> specifically, they argue that the means for collecting data via OONI do not meat basic rules for ethical standards, since the individual risk of running ooniprobe in "red flag" countries does not outweigh the potential benefits
17:15:55 <agrabeli> potentially
17:16:07 <agrabeli> sbs: I think these are some hard questions we should be asking...
17:16:23 <agrabeli> ideally we would like academic researchers to use ooni
17:16:52 <agrabeli> but it seems that using OONI would not meet IRB ethical standards
17:17:12 <willscott> agrabeli: i'd hope that concern is contextualized in terms of some demographic, like normal individuals?
17:17:40 <agrabeli> willscott: yes
17:17:41 <willscott> i feel like there's context and that it might be okay for an advocacy group to run the measurements, but we want to be cautious advertising to individuals when there's potential danger
17:18:16 <agrabeli> it's considered much safer when diplomats, for example, run ooni in high risk countries, since they enjoy immunity from prosecution
17:18:54 <willscott> sure, but diplomats often have exceptional vantage points
17:19:12 <anadahz> So to better re-phrase limiting means imporving OONI's informed constent without posing any software limitations?
17:19:54 <willscott> i'm happy to take a look on ooni's position around ethics. I managed to get satellite through that gambit, and a bunch of it is perseverance and sticking to what we think is safe
17:19:57 <agrabeli> anadahz: I think the hard question here is whether and to what extent we should be limiting the use ofthe software in certain countries or networks
17:20:35 <agrabeli> because no matter how informative and robust an informed consent policy is, that still does not deem the means of collecting data as "ethical" under standard IRB rules on ethics
17:20:55 <willscott> ooni is already being used in academic reports, and hasn't yet been directly flagged by an IRB
17:21:10 <willscott> most IRBs won't even touch it because the network measurements don't fall under their definition of 'human subjects'
17:21:36 <agrabeli> willscott: that's good to know
17:21:48 <willscott> so what we're really doing is setting benchmark norms for the ethicists who have embedded themselves into the network measurement academic community
17:22:01 <willscott> and those continue to fluctuate quite a bit
17:22:33 <agrabeli> indeed
17:23:18 <agrabeli> so in terms of sharing their feedback with you all, they are suggesting that we limit OONI in "red flag" countries to diplomats and VPNs - thoughts on this?
17:23:33 <agrabeli> *further thoughts
17:23:52 <anadahz> Technically speaking limiting OONI software is not ideal (at least not from my view point). Even if it was desirable to do so the software can't be limited since it's based on a free license and should not pose any restrictions to the users running this software.
17:23:55 <hellais> something worth looking at is also this: http://networkedsystemsethics.net/
17:25:57 <sbs> agrabeli: I'd say that, in any case, if there should be a mechanism for diplomats and the like to run the software, there should be a way to bypass the block similar to adding a flag on command line or typing "I HAVE UNDERSTOOD"
17:26:05 <willscott> * sounds like 'we know better than you what is good for you'. information is good, but no reason to be patriarchal
17:27:09 <willscott> * nobody has ever gotten in trouble for collecting network measurements
17:27:21 <willscott> (meaning risks are purely speculative)
17:27:28 <anadahz> sbs: But even if we do so what effect this will have? Get more people scared?
17:28:17 <sbs> anadahz: I don't know and am not happy about that, my comment was purely that it would be suboptimal to prevent it from running without any form of bypass
17:28:39 <willscott> * ooni is currently sufficiently technical to operate that only users who understand the risks of surveillance and that it will be visible to their ISP are able to collect measurements
17:28:39 <sbs> also, how would you prevent it from running? using client code or using the bouncer? or how?
17:29:39 <anadahz> as I said technically right now ooni-probe requires a new license to even do this, but I think we are currently discussing of the possible good/bad outcomes?
17:29:58 <sbs> anadahz: why it does require a new license?
17:30:06 <willscott> agrabeli: do we need to respond to the harvard people? what are the next steps from your perspective?
17:30:49 <agrabeli> willscott: Yes, I'll be replying to the Harvard people this week.
17:31:23 <agrabeli> I have implemented some of their feedback, re the legal section of the informed consent policy and the software license
17:31:57 <agrabeli> I plan to ask them whether they have contacts with diplomats or know who we could reach out to for this
17:32:02 <willscott> i would argue that we will include appropriate warnings, but that it is infeasible technically and due to core model to restrict access to the software
17:32:09 <agrabeli> so as to reduce risk in red flag countries
17:32:35 <sbs> what is the risk of ignorning what harvard people advocates for?
17:32:42 <agrabeli> But I would also like to present to them OONI's stance on their suggestion regarding the question that I raised
17:33:24 <agrabeli> sbs: There is no risk, but we have asked for their advice and so I think it's good to have discussions and to work together towards the best possible framework for informed consent
17:33:34 <anadahz> sbs: for what i know it's inappropriate to limit usage of a software in BSD-2-clause (ooni-probe license)
17:34:08 <agrabeli> That said, we don't have to blindly apply everything that they tell us, but I think it's good to have these discussions, possibly re-evaluate our policies and so on
17:34:10 <catfish99> it’s not so much ignoring Harvard, but ignoring - leading/key academic institution. Agree with others that pro-actively thinking IRB approval and issues helpful for broader deployment and use in academic research
17:34:57 <vecna_> sbs agrabeli I guess the risk only happen, if some OONI-user get trouble, and OONI willingly underestimate the risk analyzed by Harvard (always keeping in mind, that lawyer are more paranoid than tor developer)
17:36:23 <agrabeli> so to my understanding, evenryone disagees with the idea of limiting OONI in "red flag" countries?
17:36:27 <sbs> anadahz: I see your point about the license... however you can code it such that if you run in country X it will exit() when it finds that... from the license point of view, I don't think this violates any licanse
17:36:46 <sbs> agrabeli: yes, I don't like that
17:37:36 <anadahz> FYI an old discussion regarding ethics on networks measurements and informed consent: https://lists.torproject.org/pipermail/ooni-dev/2014-December/000205.html
17:37:38 <willscott> i don't like it either. i don't think i'd trust ooni / harvard / some central body to decide what the 'red flag' countries are?
17:38:45 <hellais> I also think it's not really going to be feasably for us to be able to assess ALL the countries of the world and identify all the ones that are red flag. That is there will probably always be some country that would be red flag that we haven't looked at
17:39:10 <agrabeli> willscott: I agree with you. Though just a clarification: They labeled certain countries as "red/yellow/green" flag based on research that we previously asked from them, in assessing user risk in those countries.
17:39:23 <anadahz> I also don't like this and any restriction on OONI software components pre-imposed to any/specific users
17:40:35 <agrabeli> Overall I am also sceptical towards the colour flagging of countries, esecially since risk is contextual and depends on many parameters that keep changing.
17:40:53 <anadahz> hellais: additionally how often these evaluations are being updated, a country that is today on a yellow flag could be tomorrow on red flag for instance after a specific occurence of an event
17:41:22 <agrabeli> I also agree with you all that limiting OONI in certain countries is against OONI's core principles, and that there are is no evidence to back up speculative risks.
17:41:53 <hellais> ok so I guess we have reached a consensus that limiting usage of OONI is not going to be either feasable nor optimal. Do we want to perhaps table this until after having gotten more feedback from the harvard people and decide on how to go abouts with informing users without impacting their ability to run it?
17:42:19 <anadahz> sbs: Actually even coding it to act like this is against the license, for some background references check 'free software and military restrictions'
17:42:34 <agrabeli> However, an open question: What responsibility should/could OONI have if users do face various forms of retribution in the future, once OONI is more accessible to broader audiences?
17:43:24 <vecna_> agrabeli: do you mean money retribution?
17:44:14 <hellais> anadahz: it's actually not against the BSD license since you are not saying "if you are person X you can't run this software", but rather it's a "feature" of the software to detect the country of the vantage and not run "when it's part of some set of countries".
17:44:25 <sbs> anadahz: uhm, I am not convinced, perhaps we can discuss this later / offline
17:44:37 <agrabeli> vecna: I am referring to potential consequences (arrests, fines, etc.)
17:45:10 <sbs> anadahz hellais: yes, I agree with hellais regarding the BSD license
17:46:17 <willscott> i think it's reasonable to have more circumspect modes of operation and documentation on why those are more appropriate
17:46:47 <sbs> willscott: for example?
17:47:24 <willscott> for example a trickle of measurements that look like they could be the user accidentally clicking a link to a sensitive domain and then backtracking
17:48:00 <willscott> i think i agree with hellais that we have reached concensus on the immediate question. we can maybe schedule some time to work on text around this issue, but maybe move on to next agenda item?
17:48:24 <sbs> willscott: ah, neat... and you would enable that operating mode in specific countries?
17:48:43 <agrabeli> Agreed. I'll circulate relevant doucmentation over the next week.
17:49:07 <hellais> ok good. moving on..
17:49:11 <hellais> #topic inclusion of a VPN endpoint inside of the raspberry pi distribution for OONI to run tests
17:49:28 <hellais> ... fo trackography
17:49:39 <vecna_> thanks! hi, I'm Claudio Agosti, my first meeting here
17:49:52 <vecna_> I'm running a data collection project (trackography) and I would benefit of many "testing point" from different countries.
17:49:52 <vecna_> So In theory, if the raspberry.py of OONI would be considered like an "infrastructured", I can use some of them, and I can dispatch around the world the same kind of hardware/software combo.
17:49:53 <vecna_> But my tool use phantomjs (and maybe other javascript sandbox tools) so is heavy in computation, can't run in the RSBPY.
17:50:07 <vecna_> So in theory a good solution can be having proxies. OONI raspberry runs some TLS/oauth authenticated proxy, only some node can be used, and they will forward my traffic.
17:50:07 <vecna_> but I know that OONI raspberry.py declare, in the users interest, the kind of traffic performed. mine are just HTTP GET request over a public list of website (without any special parameters), but the proxy imply a potential arbitrary traffic.
17:50:07 <vecna_> So can be an option in user side (a checkbox to tick?), and/or can be implemented a filter in the proxy (permitting only HTTP GET), and/or can be a detailed accounting of the operations done via the proxy.
17:50:13 <vecna_> Generally speaking, if a fellowship get accepted that distributed infrastructure can became handy. I can take care of the proxy code/settings/auditing in that case.
17:50:13 <vecna_> Every new device will contribute also to OONI network.
17:50:29 <vecna_> (EOF)
17:52:34 <sbs> vecna_: when you say "only some node can be used", you mean that some raspberry would run trackography?
17:52:40 <willscott> this feels like it dovetails with orchestration
17:53:46 <vecna_> sbs: I mean that I don't need all the nodes, just some. so can be an option not active by default. for sure - RSPBPY will never run trackography - that is the reason to have a proxy
17:54:17 <willscott> which i guess would be setting the initial expectation that we don't have a way to do this sort of central coordination of 'pushing' measurements now, and it'll be ~6 months before we get there at the current schedule
17:54:21 <sbs> vecna_: got it
17:54:24 <vecna_> willscott: ah, good, I'm not aware of that software. but at the moment the fellowship is not yet confirmed, so I've not made plans in details nor research
17:54:50 <catfish99> a study of internet controls in Venezuela  was recently completed by several ngos there. They used OONI as the testing tool. Let me know how best to schedule briefing ahead of report lauch with key ooni folks
17:55:29 <willscott> catfish99: great! is this a time that works for you?  maybe the same time but a different day this week we can dedicate to your briefing?
17:55:42 <anadahz> Hm.. that's an interesting inclusion feauture, however given the fact that VPN has the (bad) habit of rerouting all network connections to a specific gateway it may causes some problems with routing or awkward ooniprobe measurement reports
17:56:00 <willscott> catfish99: i think ideally tomorrow / wednesday to make it easy for agrabeli
17:56:11 <vecna_> willscott: for me a suitable option is also patch the software having a proxy and deploy these (customized) raspberry to be used by my network. but means loosing all the nodes available in OONI
17:57:00 <willscott> vecna_: doing your own deployment may be an easy thing for you to do short term. especially if you just grab a standard linux image with something like resin.io you should be able to do that fairly painlessly
17:57:07 <vecna_> anadahz: I was not thinking to VPN also to avoid any network layer mistake. HTTP GET for me are enough, that's why an HTTP proxy fit better
17:57:25 <vecna_> willscott: yes but is what I want avoid
17:58:16 <hellais> yes I think the orchestration is necessary to have this be integrated in a way that it doesn't interfere with the network measurements of ooniprobe. Having a proxy means that whatever bandwidth is required for your testing is multiplied by a factor of 2
17:58:19 <vecna_> willscott: you know, separation of duties :) if I can just help in a small software side and benefitting of a worldwide network, much better. btw all the data collected are open data, so can be considered as part of the measurement
17:59:07 <vecna_> hellais: I agree but, with an API that declare when the device is running and when is not, I can distributed the testing only in the "empty" moment
17:59:34 <willscott> vecna_: right. that's part of what we're calling orchestration
17:59:49 <vecna_> ack
18:00:49 <anadahz> vecna_: This would be nice and pretty straight forward to do, ideally it will be nicer for the user to decide if they would like to run trackography tests ut I don't see any issues with that.
18:00:50 <vecna_> so, I don't need an answer now, no consensus need. raising this interest was my only goal today, and get some primary feedback
18:00:57 <willscott> i guess for now, keep us updated on your progress and track our progress on orchestration
18:01:08 <willscott> i don't think we have tickets / bugs super well tagged at the moment, which is a separate issue :)
18:01:19 <vecna_> good, thanks
18:02:30 <anadahz> catfish99: Do you think that the findings should be first discussed publicly or is it OK if some/any of the key findings are discussed here?
18:04:14 <catfish99> i was an advisor to the project and authors were keen to brief and have a conversation with the ooni community ahead of the public report launch
18:04:59 <catfish99> it is more a pilot project - so feedback is helpful!
18:06:11 <willscott> seems great to have a blog post ready to go in coordination with the release
18:06:35 <catfish99> agree!
18:06:52 <catfish99> that’s the interest to have a briefing :) i’ll follow-up and coordinate with you
18:07:02 <hellais> catfish99: yes we would love to give feedback and look at the report. Andres showed me an early version of the report in valencia some months ago.
18:07:42 <catfish99> there report is ready in spanish. It’s being trnaslated, so a english version is available
18:07:46 <catfish99> too
18:11:14 <anadahz> catfish99: When do you want to make this report public?
18:12:19 <catfish99> report launch is later this month. i can’t recall specific date. will post to list
18:14:43 <willscott> other agenda items?
18:15:24 <anadahz> I think we are a bit overtime but if the rest of the people are OK with this we can move on
18:15:56 <hellais> yes let's try to at least briefly cover the other items
18:16:16 <hellais> I would table the trac vs github discussion as I think it's going to be a big rabbit hole that we shouldn't dive into now
18:16:35 <hellais> #topic possibility to introduce a kind of tickets sprint
18:17:08 <catfish99> thanks all
18:18:05 <hellais> I think this idea of doing some ticket sprints to close invalid tickets is a very solid idea. When do we want to do this?
18:18:56 <anadahz> I think it makes sense to do this in regular intervals, but in short periods like 10-15 mins.
18:19:47 <willscott> hellais: do you think we should all be online too coordinate, or can we do this asynchronously?
18:22:34 <hellais> I guess in the end it's not essential that we are all online at the same time, though it's probably smart to be mindful of timezones to be able to reach out to other during that period when questions arise about them
18:23:38 <hellais> I plan to set some time aside tomorrow afternoon (at around 16:00 CEST) to clean up the tickets on trac.
18:25:02 <anadahz> hellais: Sounds a plan I 'll try to be around before/after and  co-ordinate on triaged, undecided tickets
18:25:23 <hellais> cool.
18:25:25 <anadahz> * and invalid
18:25:25 <hellais> moving on
18:25:41 <hellais> #topic options on how to collaborate better with the metrics-team
18:25:49 <hellais> anadahz: did you have something specific in mind regarding this?
18:26:16 <hellais> I guess one thing that we should begin doing is to attend their meetings and see what it is that they discuss there that could be relevant
18:26:45 <hellais> The time and date is Thursday at 14:00 UTC in #tor-dev on OFTC
18:27:03 <anadahz> True, metrics-team runs bi-weekly IRC meetings, next is on: May 5, 2016
18:28:55 <anadahz> I can manage to attend the next one but I'm not sure if I can follow
18:30:41 <sbs> hellais anadahz: okay, I will also be around around 16:00 CEST for the tickets cleanup
18:34:07 <agrabeli> I can also help tomorrow at 16:00 CEST for the tickets cleanup
18:35:12 <hellais> ok let's move onto the next item.
18:35:29 <hellais> #topic provide list of easy tasks
18:35:44 <willscott> this seems like part of the bug cleanup?
18:35:57 <hellais> yes exactly I was about to say
18:36:16 <hellais> I think that while cleaning up the bugs we will probably want to flag some of them as easy.
18:36:38 <hellais> Also I think that some time needs to be spent in creating new issues for all the things that we have to do.
18:36:53 <hellais> In particular we should begin creating issues and milestones for the OTF deliverables.
18:37:42 <hellais> though this raises a age old debate in which issue tracker we should be using.
18:37:55 <sbs> hellais: I was about to say so :-)
18:38:11 <hellais> the current state of tickets is a mess, in that there are a bunch of tickets in trac that are not on github and vice-versa
18:38:33 <hellais> as I have already expressed in the past I am quite against us using trac
18:39:25 <anadahz> I think we shouln't really mix these 2 topics
18:39:27 <hellais> the reasons have mainly to do with the terrible usability of trac, the fact that we don't have separate issues for each of the software components of OONI, the fact that it's not tightly integrated into the code review process
18:40:12 <anadahz> We just need a simple and clear "page" that explains some easy things a person was never involved this OONI can do right away
18:40:58 <sbs> hellais: endorsing your opinion on trac and expressing my preference for github
18:41:35 <anadahz> currently both Trac tickets and Github issues don't provide this information and a person needs to understand the cryptic language that is being used in bug reports
18:42:18 <hellais> anadahz: I think that having a page for something like this is prone to making the information on such page before very quickly obsolete. We can just introduce a "easy" label to the tickets and flag issues that are easy and have a link to the formed serach query somewhere in the readme
18:42:21 <sbs> anadahz: do you suggest a sort of CONTRIBUTING.md?
18:42:54 <anadahz> hellais: so let's make sure that we update this page then
18:43:23 <anadahz> sbs: Yes but making it available on OONI's main website
18:43:24 <sbs> hellais: +1 on easy... maybe we can also say to people (if we don't say already) that we're available to discuss / review patches / help at a specific time?
18:44:24 <anadahz> sbs: hellais we should not impose that people should code in order to contribute
18:44:53 <sbs> anadahz: makes sense, you're right
18:44:59 <hellais> anadahz: not all tickets have to be about code related tasks.
18:45:24 <anadahz> there are many ways on how they can contribute but these are not currently either on Github issues nor in in Trac tickets
18:45:59 <sbs> anadahz: anyway, I understand the value of saying somthing to the website but I also have the concern that the more distant something is from git repository, the less frequently developers see it and/or remember to fix/update it
18:46:06 <anadahz> Other than that when people see tickets tend to run and are afraid to contribute by using them
18:46:19 <sbs> anadahz: hehe
18:46:36 <sbs> anadahz: what do other projects do to solve this needs?
18:46:37 <anadahz> sbs: Currently OONI's website in on git
18:46:44 <hellais> anadahz: then maybe we can do something where we put the modes of contribution that are static in a document and the ones that are going to change inside of tickets?
18:47:44 <sbs> anadahz: sure, I know, but I tend to think that changes across repositories after a change are less likely to happen than changes within the same repo... in any case mine was minor objection that we can table
18:47:55 <hellais> like the static page can talk about contributing measurements, adding lists of URLs to test to the citizenlab test lists, searching through the explorer for interesting cases of censorship etc., while for tasks that once they are done they don't have to be repeated we use issues?
18:48:01 <anadahz> sbs: torproject for instance has different categories on how people could help
18:49:23 <anadahz> hellais: sbs we can add a Contribute file in all repos that is going to be called by ooni-web git repo when the site is being compiled and published
18:49:39 <anadahz> hellais: exactly!
18:50:14 <anadahz> sbs: ref: https://www.torproject.org/getinvolved/volunteer.html.en
18:50:23 <sbs> anadahz: good point about torproject, was checking it out!
18:50:52 * sbs is hungry #nudging :-P
18:51:33 <sbs> anadahz: re the contributing file, I was also reading that there is limited possibility to customize a new contribution / issue... maybe we would like to take advantage of this?
18:52:17 <hellais> yes indeed I think we have gone way to much overtime at this point. I would say we continue going through the remaining points in next weeks meeting.
18:52:36 <willscott> sounds great
18:52:44 <sbs> (e.g. https://github.com/isaacs/github/issues/99)
18:53:57 <anadahz> sbs: perhaps we should use gitlab and setup out own structure
18:54:35 <sbs> (here! https://github.com/blog/2111-issue-and-pull-request-templates)
18:55:19 <anadahz> just FYI Github it's the only non free infrastructure that currectly OONI uses considering that we will be using AWS servers only for backup
18:55:22 <sbs> anadahz: hmm, I'd rather continue using github: the more infrastructure, the more maintainance burden
18:55:35 <hellais> sbs: +1
18:56:42 <hellais> anyways we are not going to reach consensus on this today, so let's for the moment table this and defer to next week
18:57:01 <hellais> thanks for attending the meeting. ciao!
18:57:03 <anadahz> sbs: there is still maintainace on github, ie: learning to work the github way
18:57:24 <anadahz> anyway we can disucuss this more on the next meeting
18:57:31 <hellais> #endmeeting