Monero Bi-Weekly Dev Meeting Note Highlights – 2016-06-05
Logs
351 lines
fluffyponyeveryone ready to start? smooth / tewinget / dEBRUYNE / ArticMine / luigi1111w / luigi1112 / luigi1114 / NoodleDoodle / gingeropolous etc.
ArticMineyes
fluffyponyhyc is excused, as he is at Pieter Hintjen's wake
dEBRUYNEslaps othe, moneromooo
dEBRUYNEdid we forget anyone? :p
fluffyponydon't think so
dEBRUYNEpages redfish
dEBRUYNEThink that covers it
fluffyponyok cool
moneromoooTraditional Dutch greeting ?
fluffyponylol
fluffyponytraditional Dutch greeting = "hallo"
fluffyponyso to start this meeting off I wanted to introduce yrashk, Yurii Rashkovskii
fluffyponyhe's our special guest for today
moneromoooo/
fluffyponya little bit of background: as everyone is aware we've been looking at formally adopting C4, the Collective Code Construction Contract
fluffyponywhich 0MQ uses
yrashkhey hey
fluffyponyforgot to start meeting-bot, sorry
fluffyponyok
fluffyponyso
fluffyponywith Pieter passing the mantel on to others one of the things that has happened is that yrashk has split some of these "soft skills" things off into something called Unprotocols
fluffyponyand what I wanted is for yrashk to tell us a little bit about C4 and COSS, and talk a bit about how C4 differs from the dreaded CoC - because adopting a CoC is simply not going to happen, but adopting C4 is a much better option
fluffyponyyrashk: the floor is yours
yrashkfluffypony: thanks for the intro!
yrashkyeah, actually Pieter has passed the unprotocols.org domain to me as well to play with the idea of extracting C4 and COSS (and more protocols in the future) into a separate domain from ZeroMQ and Digistan projects.
yrashkas a side node, I think that action itself was very much in the spirit of C4 — it was a quick decision when I confirmed the fact that I want to volunteer, and the domain was passed over.
yrashkwhat actually has drawn me to C4 was 1) its simplicity and 2) the rules that seemed to lead to less tension between people
yrashkit's hardly possible to eliminate those, of course, but it's easy to create "hot spots" unintentionally
yrashkI was thinking a lot about situations when things got heated before and when I myself got an urge to say things I later regretted
yrashkand I saw that it was often over a value judgement
yrashk("do we need a feature X?" "do we implement it this or that way?" etc.)
yrashkon the other hand, I had two arguments against CoC
yrashkone was the Opalgate (https://github.com/opal/opal/issues/941), second one was a tad more complex… it felt like it's just a tool to punish or eject people… a guillotine. something not focused on the positive but rather on handling the negative stuff.
fluffypony100% agreed
yrashkwith C4, the main rules of the game were pretty simple: maintainers can't hold up your patch because of your value judgement
yrashkeven if it is stupid
yrashkby the contract, everybody has a right to contribute
yrashkthe contributions must get merged in quickly (possibly after passing some sanity tests, like travis ci or a quick glance — that said, Pieter says, merge anything — you'll get a permanent record of trolls as well)
yrashkso instead of having a hierarchy of contributors (maintainers' opinion being more important than others' by default), it's rather a flat space where maintainers' role is rather administrative, to enforce the process.
yrashkif they (like anyone else) have a value judgment, they can express it either as another PR, or they comment on the patch after the patch got merged in.
yrashkno bike shedding, no gatekeeping
yrashkeverything is record. anything can be easily reverted.
yrashkis recorded*
yrashkthere's, however, an important philosophical principle behind. My current thesis (after conversing with different people) is that those who believe in individual intelligence (as opposed to aggregate group intelligence) have a harder time accepting C4.
yrashkI met people who strongly believe that their experience and intelligence justify them being gatekeepers
yrashkPieter does talk about this in his books… basically arguing that individual intelligence applied to a particular work is rather a product of luck, not a systematic thing
yrashkanother important aspect of C4 that helps justifying just about every incoming PR, is that they are REQUIRED to contain a problem-solution statement (http://rfc.unprotocols.org/spec:1/C4/,section 2.3.7)
fluffypony'A patch commit message MUST consist of a single short (less than 50 characters) line stating the problem ("Problem: …") being solved, followed by a blank line and then the proposed solution ("Solution: …").'
yrashk if a patch solves a particular problem instead of doing something that "might be helpful" or a "nice thing to do", it's easier to form your own opinion about the patch and see if any corrective measure should be taken
yrashk(should I send a reverting PR if it is a total and utter BS? should I help improving this? etc.)
yrashkI guess this braindump is good for starters. I'll take questions, if any?
fluffyponyok so my first questions when I read C4 was about how it deals with people who are disruptive
moneromoooDo you end up with a pile of crap in git, making view diffs a pain, bisect impossible, and generally having to waste time with crap ?
fluffyponyhow does it do so in a non-guillotine manner ?
yrashk(also, my short article on the subject https://blog.eventsourcing.com/productive-welcoming-vs-code-of-conduct-656b1571ddd6)
yrashkfluffypony: first important thing, the way I understand it, is getting everything logged. merge disruptive people's commits. this way you get a permanent log of their behaviour.
yrashkfluffypony: the rest is no different from other approaches: discuss the situation, if a correction can't happen, ban/eject
fluffyponyyeah I gathered the focus was on people self-correcting instead of being forced to correct
yrashkmoneromooo: you tell me https://github.com/zeromq/czmq/commits/master (as an example) — but basically, at least in my rationalization behind this, with great powers come great responsibilities
yrashkwhen you treat people like adults, they tend to behave more like adults
yrashkresulting in better ORs
yrashkPRs*
fluffyponyI think the worst case scenario is someone submits a PR that intentionally introduces a backdoor, or intentionally breaks things
yrashkI see this "optimistic" merge strategy as a way to treat people like adults
fluffyponyin which case the reverted PR is a black mark against them
moneromoooYou assume good faith, and a single bad faith person can throw a lot of crap in.
yrashkfluffypony: exactly, a permanent record (as opposed to a rejected PR, which might be lost over time)
fluffyponymoneromooo: the issue is that doing it the other way means a bad faith person can waste everyone's time
yrashkmoneromooo: just like anybody can throw a lot of crap in, it can be thrown own the same way
moneromoooBut why would we want a permanent record of spam patches in the first place ?
ArticMineSo the concept is it is easy to undo / revert damage while leaving a cleat and objective trail for community accountability
moneromoooyrashk: I'm worried about the history here, not the snapshot.
yrashkmoneromooo: because that helps identifying the bad actors at a later point ("yup, known spammer")
moneromoooI imagine someone wanting to DoS us would not use the same email over and over again. They're good at sock puppets.
yrashkit's a bit like a TSA thing — assume any passenger can be a terrorist and check everybody or do the intelligence work to single out bad actors.
moneromoooAppeal to emotion.
yrashkmoneromooo: I guess it is highly dependent on the nature of the project — how many bad actors are actually interested to disrupt the project
fluffyponymoneromooo: consider it this way - if I'm compiling every-single-PR on every-single-platform and then testing-each-platform that's like an 2-3 hours per PR
fluffyponyso how easy is it to waste my time :-P
yrashkthat's actually a worse DoS
moneromoooDo you do that ?
yrashktime is the most valuable thing
yrashkwell, any PR review takes time
yrashkand delays releases further
fluffyponymoneromooo: not since we've introduced that brief-code-review process, I just merge based on a visual inspection or a review by some known contributor
fluffyponysomeone will compile it and see it's broken, and that someone doesn't have to be me
yrashkC4 doesn't actually say the code should not be reviewed
moneromoooI think there are a large number of possible positions between "compile every single PR and test on all platforms" and "rubber stamp everything". For instance, "have a look and reject if it doesn't pass the smell test".
yrashkit's just done after the merging
fluffyponymoneromooo: we'll still have smell tests
moneromoooThat seems good to be ("I just merge based on a visual inspection or a review by some known contributor").
moneromooo(and I try to review those fwiw)
fluffyponyalso the action AFTER a failed smell test is important
fluffyponyie. do we then have a long, drawn-out convo on github
fluffyponyor do we merge and revert, then explain to the person why that happened
moneromoooAs for building, you said you'd like a build bot IIRC. That'd help a lot there.
moneromoooBut the things I'm worried about are not held off by a build check.
yrashkI use travis-ci so I can quickly see if PR breaks existing tests
fluffyponyyeah a build check solves a small subset of issues, 100% moneromooo
moneromoooMaybe I'm paranoid, but I totally see part of the BCT jerks spamming our tree just because.
yrashkdo they do this right now?
moneromoooNot to my knowledge.
fluffyponymoneromooo: it's MUCH easier to deal with that if we merge-and-revert than if we analyse and have long github discussions
yrashkone of the main ideas behind C4 is to incentivize the positive contributors to get their stuff in quickly, without painless waiting and discussions
yrashkI've beed in a situation where it just becomes so painful to abide by all the maintainers' wants to get something in
fluffyponythat PR is over a year old
yrashkor when the maintainers are busy with other projects, or don't care about a particular problem enough to get my stuff in quickly
yrashkwithout painful waiting*
fluffyponyand there are lots like that - full of discussion, "concept ACKs" and so on
dEBRUYNE<moneromooo> As for building, you said you'd like a build bot IIRC. That'd help a lot there. <= Zcash has a build bot afaik, might want to look into that
fluffyponywe use travis on Kovri
moneromoooWhat are the problems now, beyond fluffypony's time ?
fluffyponybut hoping for a more OS-complete buildbot
yrashkthe other way to look at it — with C4, you have all contributors as reviewrs
yrashknot just a handful of maintainers
yrashkbecause everybody can initiate a corrective action
fluffyponymoneromooo: the main problem is that we don't want to become exclusionary, where only a handful of special contributors actually have successful PRs
moneromoooThat would not happen if there is a large enough numbers of people who can review and ack something.
moneromoooAnd doing so would not need so muvch time from you either.
yrashkyet another way to look it, if you have gatekeepers, they would have biases of different kind when looking at a patch, conscious or subconscious; C4 helps making project more diverse as value judgement or more subtle biases don't affect the input.
yrashk(speaking of C4 vs CoC)
moneromoooWhat is CoC ?
yrashkCode of Conduct
fluffyponymoneromooo: Bitcoin has significant numbers of people that can review and ACK, yet there are 102 open PRs stuck in PR-review-hell
yrashkCoC is about prohibiting certain types of behaviours and topics
moneromoooThis may be so, but I do not believe a free for all is better.
yrashkin the name of attracting a more diverse set of contributors
moneromooo(or at least, not before we have that problem)
yrashkwhile removing gatekeeping/biases from reviews gets diverse opinions in proactively
yrashkat least that's the hypothesis
fluffyponymoneromooo: ok so consider this: what would we do if a PR was submitted from an unknown person that increases the block time to 4 minutes
moneromoooBias is a fair point, but if there are many reviewers, then that should not matter much, iunless they all have the same ones. And if they do, maybe there is a good reason.
merkaba(I know you guys are in the middle of other stuff. don't mind me. If there is anything I can help with I am ruby developer)
moneromoooThat'd probably fork at once.
yrashkmoneromooo: many projects are started by very small teams that are likely to be less diverse. therefore original maintainers might have similar biases.
fluffyponymoneromooo: I mean, would we merge the PR, or not ?
fluffyponyhi merkaba, and welcome :)
yrashkI think in the case of this PR (block time), first important thing to consider is "does it have a valid problem/solution statement"
moneromoooI'd hope not, but you're not allowed to then magic other assumptions after I said that :)
yrashkmaybe there's a problem nobody thought about?
merkabafluffypony, thank you
ArticMineThen the question becomes is the problem valid?
moneromoooIf there's a problem nobody thought about, surely a reviewer would ack it ?
fluffyponymoneromooo: so the only difference under C4 is that we merge-and-revert and then tell the committer that they have to at least discuss something that controversial on the forum or on reddit or in dev meetings or something
moneromoooSo, same result, except a spammed git history ?
moneromoooI do use git history :/
fluffyponybut spammed for a reason
fluffyponya revert won't affect git bisect / git blame, I don't think ?
moneromoooIt will affect blame I think. It will certainly affect bisect time.
moneromoooRegardless, I object to it for other grounds anyway (it seeming like shooting ourslves in the foot).
fluffyponyI think that maybe extreme examples like "change the block time" are bad for what I'm trying to illustrate
moneromoooIf/when there is a problem with people's patches being held up, and this causing contributors to become dissatisfied, we can talk about it again.
moneromoooBut then, the solution should consider something not totally at the extreme of "let's merge anything".
fluffyponybut moneromooo, I think we can do the opposite of "possibly causing dissatisfied contributors" - I think we can be extremely welcoming to contributors
ArticMineIs a middle ground possible here?
moneromoooThat'd seem to be a great idea. I find monero very welcoming tbh.
fluffyponywell the current pitch is "let's merge everything once it's been reviewed by a known contributor"
redfishwhat is the goal of introducing a new contribution guideline? what problem is being addressed here? attracting potential contributors? treating dissatisfied contributors?
fluffyponyso we still have that firewall
fluffyponyredfish: it's about establishing protocol that will survive through to when we have 500+ contributors
moneromoooDo you mean "we'd still have" ?
fluffyponymoneromooo: yes I do
fluffyponyI hate the idea of "dev worship", where a single contributor is lorded over others, or viewed as being able to cure cancer
moneromoooThen I agree. I was iunder the impression that there'd be no review by a known contributor. Sorry about that :D
fluffyponyto the exclusion of newcomers
yrashkC4 kind of helps addressing the "problem of elders"
redfisha newcomer can be dissuaded by review-block, but the newcomer should really have thicker skin
redfishbe careful of working with a strawmen for a newcomer contributor
moneromooo17:35 <@fluffypony> moneromooo: not since we've introduced that brief-code-review process, I just merge based on a visual inspection or a review by some known contributor
expezCode review on github is often about increasing code quality. Most contributors aren't cpp experts. If you just merge everything the code quality in the project will gradually decrease until changes become very hard. Or the regular contributors will have to cleanup the area they want to change prior to doing the work the actually wanted. This means a few bad apples will slow everyone down.
redfishthe attitute of "you don't want my patch? then, fuck you all" should not be encouraged
moneromoooThen:
moneromooo17:53 <@fluffypony> well the current pitch is "let's merge everything once it's been reviewed by a known contributor"
moneromoooAnd:
moneromooo17:54 < moneromooo> Do you mean "we'd still have" ?
moneromooo17:54 <@fluffypony> moneromooo: yes I do
moneromoooSo I don't see what would change, then.
expezIf there's no discussion, just accept or revert, only the experts will make contributions whereas with some guidance a lot more would've been able to.
moneromoooCurrently: an ack by a known contributor.
fluffyponyexpez: so by the same token every technical / scientific / medical article on Github should have declining quality until it's illegible garbage :-P
expezfluffypony: I can't speak to that. I haven't seen any articles written by acretion.
fluffyponyI jest - I'm not suggesting the code be written by Wikipedia contributors
fluffyponybut let me use a practical example
fluffyponya new contributor submits a new feature, but it breaks the Windows build and also doesn't include unit tests
fluffyponyoption 1 is that we back-and-forth on his PR until he has it "perfect" by some undefined definition of perfection
fluffyponythis leads to ANY contributor being frustrated, because they've put in effort and maybe they don't even have a Windows box to work on
fluffyponyif, instead, we merge the PR and then create an issue for the broken Windows build + issues for the lack of tests, then ANYONE can fix those
fluffyponynot just the original contributor
yrashkI think you really nailed it here: "undefined definition of perfection"
moneromoooDude. Why do you always present the alternative as the other extreme ? This is also a problem, but we don't have it right now.
redfishanyone can push commits on top of a PR branch
fluffyponyredfish: yes they can, but until when ?
redfishuntil the build is fixed and the unit tests pass
botanonimalKovri meeting starts now but everyone is on a roll - and I'd like to read this huge backlog :)
fluffyponymoneromooo: sure, but that's like saying we shouldn't adopt any sort of governance structure because we're "too small for governance"
moneromoooNot really. Maybe a bit.
yrashkfluffypony: I decided to adopt C4 at eventsourcing.com before it's actually needed — the later you are the harder it is to change the governance
fluffypony^^
moneromoooOK, that is a fair point.
fluffyponyliterally the only change from a contributor perspective is you have to include a Problem…Solution statement
moneromoooBut we could adopt a governance that's not as seemingly footgun.
fluffyponynothing else changes
moneromoooNot the merge it all and revert at once ?
fluffyponythat affects those with push rights, not contributors as a whole
fluffyponyand because we're small we'll probably not even follow that to the letter all the time
fluffyponyBUT we'll have a documented process which contributors will be able to find and understand
ArticMineThere is a difference between a controversial change to the social covenant and failure to build for a particular OS
yrashkin fact, C4 adds a review layer of a sort for "proven" maintainers as you can't push to master directly
fluffyponyArticMine: agreed
fluffyponyhttp://oss-watch.ac.uk/resources/governancemodels <- this is a good read
yrashkbut other maintainers have to merge your PR in
fluffyponyfrom that article:
lpaalp1hello
moneromooohi
fluffypony"It is never too soon to define a suitable governance model. Without one, the chances of third parties wishing to contribute are considerably reduced. This is for a number of reasons:
fluffypony- potential contributors will not know how to contribute
fluffypony- they will not be sure what will happen to their contribution
fluffypony- the project will not look serious about engaging with third parties
fluffypony- there is no visible assurance that contributions will be managed in such a way that they will remain of value to the original contributor
fluffyponySince you never know when a contributor might stumble upon your project, it is important to be ready from the earliest possible date."
moneromooo"the project will not look serious about engaging with third parties" sounds like bullshit.
fluffyponyyou'd be surprised by how many people who code for a living are afraid to submit a PR, moneromooo
moneromoooThe rest, OK.
fluffyponywe have fluffy ponies and cows and all sorts, not everyone wants to be in the middle of a farmyard
moneromoooThat may be so, but the sentence doesn't really mention that.
redfishthis quote assumes strawman for a contributor
fluffyponyhi lpaalp1 :)
redfishimho, the danger from a troll newcomer is greater than a danger from a biased old-timer
fluffyponyredfish: C4 provides options to deal with trolls that don't self-correct
moneromoooI'm totally fine with having a CONTRIBUTING file, or HTML page somewhere, etc, fwiw.
fluffyponyand it does so in a way that is least disruptive to the community as a whole
moneromoooWell, I do not agree with this, since the harm to history has already been done.
moneromooo(assuming we're back to merge-first, rather htan wait for an ack from a well known contributor)
fluffyponyno we're not back to that, lol
fluffyponythe review-first model still stays, we're just bolting C4 on top of that
fluffyponyat any rate, we've gone significantly over time, and we've only had one point for discussion, lol
moneromoooOK. I feel like I'm being lied to here for some reason…
fluffyponyI think let's bounce this around over the next two weeks
moneromoooMaybe because the discussion about it months ago was merge first.
fluffyponyand then at the next dev meeting we can make a decision if everyone is comfortable
fluffyponymoneromooo: that hasn't changed, we've just added the eyeball-review bit per the discussion with smooth ages ago
moneromoooOK. Thanks.
ArticMineYes this needs a lot more thought and discussion before a decision is made
fluffyponyyes absolutely
fluffyponyso before we move on to Kovri
fluffyponytwo quick things
fluffypony1. moneromooo - can you give us a brief update on how the RingCT stuff is going
fluffyponyand 2. dEBRUYNE wanted to discuss 0MQ briefly
fluffyponyalso thanks for attending yrashk - much to think about and discuss :)
moneromoooWell, I'm getting to know it. I'm hacking on bits at a time, so I get to learn bits of it at a time.
yrashkfluffypony: thanks for having me!
moneromoooIt's progressing anyway.
dEBRUYNEre: 0MQ -> tewinget is going to pick that up (i.e. continue). I am drafting the FFS proposal on his behalf and hope to put it out soon (probably at latest by monday/tuesday).
fluffyponymoneromooo: do you need any extra help, or are you ok with things at the moment ?
moneromoooRewrite, not contunue, AFAIK.
moneromoooI'm ok with it, but I'll have questions for shen, most certainly.
fluffyponykk
fluffyponyok so I think let's move on to Kovri - anonimal, the floor is yours
dEBRUYNE<moneromooo> Rewrite, not contunue, AFAIK. <= Correct. Rewrite is in a sense also continue right? :P
Sources and notes
- Meeting log: Overview and Logs for the Dev Meeting Held on 2016-06-05, getmonero.org. The official post carried the raw log and pointed readers to Hello Monero for the overview.
- Original Hello Monero URL slug recovered from the Wayback Machine index; the original page content did not survive, so this reconstruction carries the log as archived by the Monero Project.