Commit f9f79654 authored by cryptochangements's avatar cryptochangements
Browse files

fix merge conflicts

parents 3f45e519 ddaff002
# General Guidelines
- Commits should be [atomic]( and diffs should be easy to read. Please try to not mix formatting fixes with non-formatting commits
- The body of the pull request should:
* contain an accurate description of what the patch does
* provide justification/reasoning for the patch (when appropriate)
* include references to any discussions such as other tickets or chats on IRC
- If a particular commit references another issue, please add a reference. For example "See #123", or "Fixes #123". This will help us resolve tickets when we merge into `master`
# [Code of Conduct (22/C4.1)](
## License
Copyright (c) 2009-2015 Pieter Hintjens.
This Specification is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.
This Specification is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program; if not, see <>.
## Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
## Goals
C4 is meant to provide a reusable optimal collaboration model for open source software projects. It has these specific goals:
- To maximize the scale and diversity of the community around a project, by reducing the friction for new Contributors and creating a scaled participation model with strong positive feedbacks;
- To relieve dependencies on key individuals by separating different skill sets so that there is a larger pool of competence in any required domain;
- To allow the project to develop faster and more accurately, by increasing the diversity of the decision making process;
- To support the natural life cycle of project versions from experimental through to stable, by allowing safe experimentation, rapid failure, and isolation of stable code;
- To reduce the internal complexity of project repositories, thus making it easier for Contributors to participate and reducing the scope for error;
- To enforce collective ownership of the project, which increases economic incentive to Contributors and reduces the risk of hijack by hostile entities.
## Design
### Preliminaries
- The project SHALL use the git distributed revision control system.
- The project SHALL be hosted on or equivalent, herein called the "Platform".
- The project SHALL use the Platform issue tracker.
- The project SHOULD have clearly documented guidelines for code style.
- A "Contributor" is a person who wishes to provide a patch, being a set of commits that solve some clearly identified problem.
- A "Maintainer" is a person who merges patches to the project. Maintainers are not developers; their job is to enforce process.
- Contributors SHALL NOT have commit access to the repository unless they are also Maintainers.
- Maintainers SHALL have commit access to the repository.
- Everyone, without distinction or discrimination, SHALL have an equal right to become a Contributor under the terms of this contract.
### Licensing and Ownership
- The project SHALL use a share-alike license, such as the GPLv3 or a variant thereof (LGPL, AGPL), or the MPLv2.
- All contributions to the project source code ("patches") SHALL use the same license as the project.
- All patches are owned by their authors. There SHALL NOT be any copyright assignment process.
- The copyrights in the project SHALL be owned collectively by all its Contributors.
- Each Contributor SHALL be responsible for identifying themselves in the project Contributor list.
### Patch Requirements
- Maintainers and Contributors MUST have a Platform account and SHOULD use their real names or a well-known alias.
- A patch SHOULD be a minimal and accurate answer to exactly one identified and agreed problem.
- A patch MUST adhere to the code style guidelines of the project if these are defined.
- A patch MUST adhere to the "Evolution of Public Contracts" guidelines defined below.
- A patch SHALL NOT include non-trivial code from other projects unless the Contributor is the original author of that code.
- A patch MUST compile cleanly and pass project self-tests on at least the principle target platform.
- A patch commit message SHOULD consist of a single short (less than 50 character) line summarizing the change, optionally followed by a blank line and then a more thorough description.
- A "Correct Patch" is one that satisfies the above requirements.
### Development Process
- Change on the project SHALL be governed by the pattern of accurately identifying problems and applying minimal, accurate solutions to these problems.
- To request changes, a user SHOULD log an issue on the project Platform issue tracker.
- The user or Contributor SHOULD write the issue by describing the problem they face or observe.
- The user or Contributor SHOULD seek consensus on the accuracy of their observation, and the value of solving the problem.
- Users SHALL NOT log feature requests, ideas, suggestions, or any solutions to problems that are not explicitly documented and provable.
- Thus, the release history of the project SHALL be a list of meaningful issues logged and solved.
- To work on an issue, a Contributor SHALL fork the project repository and then work on their forked repository.
- To submit a patch, a Contributor SHALL create a Platform pull request back to the project.
- A Contributor SHALL NOT commit changes directly to the project.
- If the Platform implements pull requests as issues, a Contributor MAY directly send a pull request without logging a separate issue.
- To discuss a patch, people MAY comment on the Platform pull request, on the commit, or elsewhere.
- To accept or reject a patch, a Maintainer SHALL use the Platform interface.
- Maintainers SHOULD NOT merge their own patches except in exceptional cases, such as non-responsiveness from other Maintainers for an extended period (more than 1-2 days).
- Maintainers SHALL NOT make value judgments on correct patches.
- Maintainers SHALL merge correct patches from other Contributors rapidly.
- The Contributor MAY tag an issue as "Ready" after making a pull request for the issue.
- The user who created an issue SHOULD close the issue after checking the patch is successful.
- Maintainers SHOULD ask for improvements to incorrect patches and SHOULD reject incorrect patches if the Contributor does not respond constructively.
- Any Contributor who has value judgments on a correct patch SHOULD express these via their own patches.
- Maintainers MAY commit changes to non-source documentation directly to the project.
### Creating Stable Releases
- The project SHALL have one branch ("master") that always holds the latest in-progress version and SHOULD always build.
- The project SHALL NOT use topic branches for any reason. Personal forks MAY use topic branches.
- To make a stable release someone SHALL fork the repository by copying it and thus become maintainer of this repository.
- Forking a project for stabilization MAY be done unilaterally and without agreement of project maintainers.
- A stabilization project SHOULD be maintained by the same process as the main project.
- A patch to a stabilization project declared "stable" SHALL be accompanied by a reproducible test case.
### Evolution of Public Contracts
- All Public Contracts (APIs or protocols) SHALL be documented.
- All Public Contracts SHOULD have space for extensibility and experimentation.
- A patch that modifies a stable Public Contract SHOULD not break existing applications unless there is overriding consensus on the value of doing this.
- A patch that introduces new features to a Public Contract SHOULD do so using new names.
- Old names SHOULD be deprecated in a systematic fashion by marking new names as "experimental" until they are stable, then marking the old names as "deprecated".
- When sufficient time has passed, old deprecated names SHOULD be marked "legacy" and eventually removed.
- Old names SHALL NOT be reused by new features.
- When old names are removed, their implementations MUST provoke an exception (assertion) if used by applications.
### Project Administration
- The project founders SHALL act as Administrators to manage the set of project Maintainers.
- The Administrators SHALL ensure their own succession over time by promoting the most effective Maintainers.
- A new Contributor who makes a correct patch SHALL be invited to become a Maintainer.
- Administrators MAY remove Maintainers who are inactive for an extended period of time, or who repeatedly fail to apply this process accurately.
- Administrators SHOULD block or ban "bad actors" who cause stress and pain to others in the project. This should be done after public discussion, with a chance for all parties to speak. A bad actor is someone who repeatedly ignores the rules and culture of the project, who is needlessly argumentative or hostile, or who is offensive, and who is unable to self-correct their behavior when asked to do so by others.
# Addendum to [Code of Conduct (22/C4.1)](
## License
Copyright (c) 2017 The Monero Project
## Language
The "Monero Site Maintainer Team" is defined in this document as the following users:
- fluffypony
- anonimal
### Development Process
- Maintainers MUST NOT merge pull requests in less than 168 hours (1 week) unless deemed urgent by the Monero Site Maintainer Team
......@@ -34,7 +34,7 @@
- name: BIT.AC
- name: Premium investment and exchange services
- name: Kaiserex
- name: Magnetic Exchange
......@@ -47,7 +47,7 @@
- name: MoneroBlocks
- name: MoneroExplorer
- name: MoneroHash Explorer
- name:
......@@ -60,6 +60,8 @@
- name: Paybee (Private Beta)
- name: Monero WooCommerce Extension (PHP)
- category: Libraries and Helpers
- name: monero-nodejs (Node.js)
......@@ -78,6 +80,8 @@
- name: Monero-PHP (PHP)
- name: Monero Payments Library (PHP)
- category: Tools
- name: nestorgames
......@@ -132,6 +136,8 @@
- name: Nerdzy Lawn Care
- name: Njalla - privacy-aware domain registration
- category: Goods
- name: CryptoMercado - coffee and snacks
......@@ -156,6 +162,8 @@
- name: Elise Hawkins Nutritional Therapy
- name: - Gold and Silver Dealer
- category: Entertainment
- name: MoneroDice
......@@ -46,7 +46,7 @@
- name: dEBRUYNE
- name: SamsungGalaxyPlayer
- name: Justin Ehrenhofer
- name: gingeropolous
......@@ -61,4 +61,4 @@
- name: Brandon Goodell (Surae Noether)
- name: Sarang Noether
\ No newline at end of file
layout: post
title: Logs for the Kovri Dev Meeting Held on 2017-07-09
summary: Brief review of what has been completed since last meeting, discussion of meta issues, and code & open tickets discussion
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
*July 9th, 2017*
# Logs
**\<anonimal>** 1. Greetings
**\<anonimal>** 2. Brief review of what's been completed since the previous meeting
**\<anonimal>** 3. Contributor FFS check-in / status
**\<anonimal>** 4. Open Meta issue review
**\<anonimal>** 5. Code + ticket discussion / Q & A
**\<anonimal>** 6. Any additional meeting items
**\<anonimal>** 7. Confirm next meeting date/time
**\<anonimal>** Hello! :)
**\<MoroccanMalinois>** hi
**\<rehrar>** Yo
**\<ArticMine>** hi
**\<anonimal>** Hi MoroccanMalinois rehrar ArticMine
**\<anonimal>** fluffypony too?
**\<i2p-relay> {-fluffypony}** yes
**\<anonimal>** Hi fluffypony
**\<anonimal>** 2. Brief review of what's been completed since the previous meeting
**\<anonimal>** On my end: testnet development and related collab with MoroccanMalinois and lazygravy + SSU/Ident collab/PR review with MoroccanMalinois (and related research/development), rehrar collab for his site related work, some collab with serhack/ericcion Italian translations for kovri-site, email + PR collab + R&D with rbrunner on the windows InnoSetup installers, Monero project work (monero svn to git for
**\<anonimal>** unbound), work with pigeons on setting up kovri.i2p (now online!), answer various IRC/reddit Q&A + related collab.
**\<rehrar>** This past week was launching the Monero website. Now that's basically done.
**\<anonimal>** Some various things here and there, I2P/Tor family node research and more.
**\<anonimal>** Some French + Russian kovri-site translations are in the works, they are in the PR pit.
**\<anonimal>** Same with kovri repo, I have yet to review the new MM PR's.
**\<anonimal>** Did we miss anything else?
**\<anonimal>** 3. Contributor FFS check-in / status
**\<anonimal>** I'm here, checked-in! MoroccanMalinois is here. Yay!
**\<MoroccanMalinois>** i will be ok with a milestone in next meeting if last PR's get merged :)
**\<anonimal>** Excellent, I'm sure they will.
**\<anonimal>** re: FFS check-in, MoroccanMalinois is doing great. I can't review myself, anyone else on point 3.?
**\<anonimal>** Well, I *can* review myself, but that wouldn't be fair now would it? ;)
**\<MoroccanMalinois>** lol
**\<i2p-relay> {-fluffypony}** lol
**\<i2p-relay> {-fluffypony}** leave it to the community to review
**\<anonimal>** With the exception of this intermittent week, point 2 shows that I've been active and busy, that I can say the least.
**\<anonimal>** Alright, moving on. 4. Open Meta issue review
**\<anonimal>** Starting from the top down, #80
**\<anonimal>** rehrar, any news on that front?
**\<anonimal>** #77 and #78, fluffypony what do you think?
**\<i2p-relay> {-fluffypony}** checking
**\<rehrar>** Sorry. Afk 2 min
**\<i2p-relay> {-fluffypony}** what's a topic
**\<i2p-relay> {-fluffypony}** lol
**\<i2p-relay> {-fluffypony}** anonimal: won't web hooks for -site and -docs be too distracting?
**\<rehrar>** This week is all Kovri for me.
**\<rehrar>** I'll be writing the brief tomorrow and presenting it
**\<anonimal>** fluffypony: well, not for me: it would be helpful because of the sometimes very large notification lists I get in github.
**\<rehrar>** I'll also be importing the tech from the new Monero website to Kovri. That which is applicable.
**\<anonimal>** Awesome rehrar
**\<anonimal>** fluffypony: is it too much?
**\<i2p-relay> {-fluffypony}** I don't mind activating it, it's your call :)
**\<anonimal>** Can we give it a trial run?
**\<anonimal>** (e.g., do it until too many people complain)
**\<serhack>** Hey anonimal
**\<serhack>** How are you?
**\<anonimal>** fluffypony: re: topics, quick link
**\<anonimal>** Hi serhack
**\<i2p-relay> {-fluffypony}** tks
**\<anonimal>** serhack: sono stanco, ma we can chat more after the meeting
**\<ArticMine>** On 4 there is Project licensing #85 impacts kovri
**\<serhack>** Oh okay
**\<ArticMine>** Was opened to get feedback
**\<rehrar>** Kovri doesn't have to have the same license as Monero, right?
**\<anonimal>** ArticMine: I took a quick look at that earlier this week, will look again now.
**\<i2p-relay> {-fluffypony}** rehrar not necessarily, but might be better if we did
**\<moneromooo>** kovri's library part will be used by monero at some point.
**\<i2p-relay> {-fluffypony}** I don't see a reason to have different licenses
**\<anonimal>** BSD-3, yes I believe so.
**\<anonimal>** re: licensing, no matter what, we'd need to adhere to the licenses of all bundled dependencies, right?
**\<ArticMine>** Yes
**\<ArticMine>** That is part of the issue in 85
**\<ArticMine>** I2P is effectively GPL v2
**\<moneromooo>** "I2P" ? The Java router ?
**\<ArticMine>** Yes java
**\<anonimal>** Huh? Java I2P?
**\<ArticMine>** java makes I2P GPL v2
**\<anonimal>** I don't see how that applies to us as we're not using any of their code.
**\<anonimal>** And most of the important bits are "free (adj.): unencumbered; not under the control of others", whichever license that equates to.
**\<ArticMine>** Not directly to kovri
**\<anonimal>** Open specification is different than implementation in terms of licensing, right?
**\<ArticMine>** but that is why 5 was opened to deal with this discussion
**\<ArticMine>** 85
**\<anonimal>** If monero goes dual-license, then we must?
**\<ArticMine>** Not necessarily
**\<anonimal>** Ok. I'll need more thought on this. I can add to the next agenda too. Does anyone have any strong feelings on this now?
**\<ArticMine>** I think it is best if we discuss it on Github under 85
**\<ArticMine>** Then we can look at it in the next meeting
**\<rehrar>** I have strong feelings to go proprietary.
**\<moneromooo>** er, we would not do that.
**\<rehrar>** But aside from that let's move on.
**\<rehrar>** I kid.
**\<anonimal>** ArticMine: ok.
**\<anonimal>** re: #63, rehrar did you figure out your git branching issue?
**\<rehrar>** Web launch took priority.
**\<rehrar>** We've been feverishly working on it and it is done for now. I've been reading into branches yes.
**\<rehrar>** Sorry, also headed to Mexico atm. :/ So my replies will be intermittent.
**\<rehrar>** Should be resolved in the next two days.
**\<anonimal>** I haven't made any new contributions to it yet so I don't think it's done for now ;)
**\<rehrar>** No, I meant the website
**\<rehrar>** Working in the website and the site is done for now.
**\<anonimal>** Ok
**\<anonimal>** re: #46, fluffypony are we still scheduled for the 20th?
**\<i2p-relay> {-fluffypony}** I have no idea - I don't have it in my calendar, has someone checked with Shay?
**\<anonimal>** Eek, I thought he sent an email after he posted in #46
**\* anonimal** will ping him right now
**\<i2p-relay> {-fluffypony}** tks
**\<anonimal>** I have a feeling he may have been waiting for more responses.
**\<anonimal>** #43, hmm
**\<rehrar>** This week. ;)
**\<rehrar>** First step is to nail down #80 imo
**\<rehrar>** Because then I can start producing some material.
**\<anonimal>** I think rehrar had thoughts on that area. Sounds like everyone is at max capacity at the moment though.
**\<anonimal>** Ok
**\<anonimal>** fluffypony, is #12 still applicable?
**\<i2p-relay> {-fluffypony}** checking
**\<i2p-relay> {-fluffypony}** yes - label bot took precedence
**\<i2p-relay> {-fluffypony}** but we'll pick that up after it's deployed
**\<rehrar>** Spoke to @fluffypony, could be resolved as early as next week
**\<rehrar>** Over one year ago. :P
**\<i2p-relay> {-fluffypony}** lol
**\<i2p-relay> {-fluffypony}** we had to choose a mail provider
**\<i2p-relay> {-fluffypony}** that took multiple face-to-face meetings
**\<anonimal>** Oh neat, label bot is online
**\<rehrar>** Can we give him a better name?
**\<i2p-relay> {-fluffypony}** only in meta right now
**\<moneromooo>** Oooh, where is the documentation ?
**\<anonimal>** Oh lol, I see, rehrar quoted my kovri comment from March 16th, 2016, heh X)
**\<anonimal>** fluffypony: so #12 is applicable but not finished?
**\<i2p-relay> {-fluffypony}** yes
**\<anonimal>** Ok
**\<i2p-relay> {-fluffypony}** @rehrar ask pigeons
**\<rehrar>** Will do.
**\<anonimal>** #9 #19 #29 #30 are pigeons territory I believe.
**\<anonimal>** Anything else on this point (meta issue review)?
**\<anonimal>** #24 #26 #27 will be useful. ajs waits patiently on #27. We can eventually make a big move on #27 when the time comes. That should be fun.
**\<anonimal>** Out of time, 5. Code + ticket discussion / Q & A
**\<anonimal>** Nothing pressing at the moment aside from the open PR's which will be reviewed.
**\<anonimal>** Anything else on 5.?
**\<anonimal>** 6. Any additional meeting items
**\<anonimal>** Nothing from me at the moment. ArticMine how urgent was meta #85 in terms of coming to a resolution?
**\<rehrar>** I think we gucci.
**\<ArticMine>** I would give it at least two weeks
**\<ArticMine>** Once we see discussion / comments
**\<rehrar>** K. Going to be crossing soon, so I'm out for now. Cya all Kovri Peeps.
**\<ArticMine>** It was promoted by a Monero dependency going to a copyleft
**\<anonimal>** Ok
**\<anonimal>** 7. Confirm next meeting date/time
**\<anonimal>** Same time, two weeks from now?
**\<anonimal>** rehrar will you be back by then?
**\<rehrar>** It's a day trip.
**\<rehrar>** I live like right next to the border.
**\<rehrar>** Ill be back before my day is over, and right to work tomorrow.
**\<anonimal>** Oh, alright, then we'll keep the usual meeting date/time.
**\<anonimal>** Thanks everyone :)
**\<endogenic>** thanks anonimal :)
\ No newline at end of file
layout: post
title: Overview and Logs for the Dev Meeting Held on 2017-07-09
summary: Discussion of open PRs and issues, 0MQ, reimagining the FFS, 0MQ, and miscellaneous
tags: [dev diaries, core, crypto]
author: dEBRUYNE / fluffypony
*July 9th, 2017*
# Overview
An overview [can be found on MoneroBase](
# Logs
**\<fluffypony>** 1. Greetings
**\<fluffypony>** 2. Brief review of what's been completed since the previous meeting
**\<fluffypony>** 3. Code + ticket discussion / Q & A
**\<fluffypony>** 4. Reimagining the FFS (discussion)
**\<fluffypony>** 5. Any additional meeting items
**\<fluffypony>** 6. Confirm next meeting date/time
**\<fluffypony>** going to skip 1 because I think we're all mostly here
**\<fluffypony>** 2. Brief review of what's been completed since the previous meeting
**\<fluffypony>** loads of stuff, lots of PRs in process and getting close to merge
**\<fluffypony>** and then the new website of course
**\<fluffypony>** 3. Code + ticket discussion / Q & A
**\<fluffypony>** so I'd like to just have a quick step through some PRs that are still in the wings
**\<hyc>** been getting deluged by readline and new sync commits
**\<fluffypony>** #1936: any input?
**\<moneromooo>** It's marked as do not merge, so I've not looked in ages. Not sure whether revler's still around.
**\<hyc>** He commented 9 days ago to close it in favor of #2055
**\<pero>** ^
**\<fluffypony>** oh I missed that
**\<fluffypony>** thanks hyc
**\<dEBRUYNE>** Which is merged already :-P
**\<hyc>** even better ;)
**\<nioc>** moneromooo: yes revler is still around
**\<fluffypony>** ok - 2023 is waiting until after the Sept fork, right?
**\<moneromooo>** Yes.
**\<fluffypony>** ok
**\<fluffypony>** #2044: tewinget, there are pending comments
**\<fluffypony>** maybe we can get this merged sometime in the next century
**\<dEBRUYNE>** tewinget commented on that here fwiw
**\<dEBRUYNE>** \<tewinget> dternyak: seems reasonable. it'd have to be on a case-by-case basis as some other things are ramping up to keep me a little busier, but for now I plan to have all the suggestions / notes from moneromooo addressed by the end of today.
**\<moneromooo>** What concerns me is that there were misc commits adding/changing RPC, and some of the stuff (ie, getinfo) is kinda reverting those.
**\<nioc>** fluffypony: tewinget said he would deal with it by the end of the day
**\<moneromooo>** It might be a pita to go through everything to check all is ported.
**\<fluffypony>** moneromooo: we'll run both JSON RPC and 0MQ in parallel for the moment anyway
**\<fluffypony>** so that should reveal it
**\<fluffypony>** #2056: needs to be backed up by a final MRL write-up
**\<fluffypony>** which I believe is WIP
**\<fluffypony>** kenshi84: ^^
**\<knaccc>** i.e. 2056 should not be merged prior to an MRL being published?
**\<jollymort>** speaking of which, wouldn't it be simpler to c&p the write-up from #2056 into a .md file?
**\<jollymort>** i mean, it's all there; but not in fancy TEX format
**\<fluffypony>** @jollymort nobody wants to review it unless it's in fancy TeX :-P
**\<hyc>** phototypesetter-ready copy or go home
**\<fluffypony>** lol
**\<fluffypony>** ok everything else is still WIP
**\<hyc>** Is this a good time to mention, still hasn't gotten much feedback
**\<hyc>** which is a bit surprising, considering the intensity of the IRC chat
**\<ArticMine>** Yes this needs feedback
**\<ArticMine>** Project licensing
**\<moneromooo>** Those can get merged: 2126 2131 2132 2133 (if diff agrees) 2135 2140 2142
**\<moneromooo>** Some newer ones are also simple, but too new I guess.
**\<fluffypony>** moneromooo: tks
**\<fluffypony>** hyc: cross-post it to Reddit maybe?
**\<moneromooo>** 2138 too if someone is qualified to review (I am not).
**\<fluffypony>** ok
**\<hyc>** hmm. reluctant to face the low signal-to-noise ratio on reddit with that ticket, but perhaps that's the only way to get eyes on it
**\<fluffypony>** anything else on this or can we move ahead?
**\<moneromooo>** I'd like to get guinea pigs for :)
**\<moneromooo>** It's mostly working fine (pending iDunk's latest test).
**\<iDunk>** ...ahem...
**\<moneromooo>** :/
**\<fluffypony>** lol
**\<moneromooo>** Well, maybe later.
**\<hyc>** would be nice to include a script to monitor network stats
**\<vtnerd>** moneromooo : I have a review in progress of that branch that I hope to get out
**\* iDunk** envisions more #2149 commits :)
**\<moneromooo>** Ah, I've got to squash before it's reviewable.
**\<hyc>** and quantify difference in bandwidth usage
**\<vtnerd>** ah so its not reviewable?
**\<vtnerd>** oh you mean squash the commit history
**\<hyc>** the commit msgs are all so enlightening so far ;)
**\<moneromooo>** Well, if you look at the diff itself, it should be. But it's a lot of shitty commits atm.
**\<moneromooo>** hyc: there's a new sync\_info command which kinda does that.
**\<hyc>** oh, cool
**\<hyc>** but you'd also need that cmd in a before- patch, for comparison
**\<mattcode>** can we frame the commit messages from #2149 and put them in a gallery?
**\<moneromooo>** Ah, it doesn't really apply before the patch. I expect people would just time a sync before and after.
**\<hyc>** :D
**\<hyc>** I think we could just grab ifconfig stats or something instead.
**\<hyc>** but whatever
**\<moneromooo>** I used iftop.
**\<moneromooo>** A bit handwavy though.
**\<moneromooo>** But at some point after startup, it's the CPU that's the bottleneck.
**\<pero>** nethogs does it per process
**\<hyc>** ok. that's a good position to be in then.
**\<fluffypony>** ok
**\<fluffypony>** moving on?
**\<iDunk>** Damn monero users. It would sync in no time if only there weren't any transactions.
**\<hyc>** Who is familiar with Docker to review #2138?
**\<hyc>** obviously I've already done those steps manually, to build Android binaries.
**\<pigeons>** I'll take a look, but I find new docker oddities and workarounds daily
**\<hyc>** cool
**\<tewinget>** oh dear, late. sorry about that.
**\<hyc>** ok I guess that's it for open tickets
**\<tewinget>** on my laptop; idk if I ever checked if I got my irc set up right on here; hyc ACK if you see this.
**\<hyc>** tewinget yes?
**\<tewinget>** kk
**\<fluffypony>** ok
**\<fluffypony>** 4. Reimagining the FFS (discussion)
**\<moneromooo>** So... moving on... luigi1111, any news about N-1/N multisig theory ? :)
**\<moneromooo>** nevermind
**\<fluffypony>** so
**\<fluffypony>** the FFS has worked fine the last few years, but we need to formalise some of the processes
**\<fluffypony>** for eg. what do we do with over-funding? currently we put it into the general fund and then use that for future FFS proposals
**\<fluffypony>** but I'm open to suggestions
**\<rehrar>** I wrote something up for it, and it had mixed feedback.
**\<rehrar>** A good deal of feedback said it was too formal, and in the Terms the Conclusion should go at the top as an Intro instead, but yeah. Any feedback is welcome. :)
**\<moneromooo>** Maybe there could be a running "monero core team" ffs, with \<pinky up> 1 million monero limit...
**\<hyc>** does that mean the next FFS proposal that gets submitted automatically gets a head start?
**\<fluffypony>** hyc: we give every FFS proposals a head start anyway
**\<hyc>** ok
**\<fluffypony>** also pero had some thoughts
**\<fluffypony>** iirc on time frames and so on
**\<pero>** hmmm yea i could look at this
**\<pero>** timeframes and scope i'd like to see more detailed in my SOWs than i have seen so far in the FFSs
**\* tewinget** runs and hides
**\<pero>** ;)
**\<pero>** it's really hard to manage work if these things arent defined
**\<pero>** and mediation/dispute resolution is impossible
**\<pero>** what i was thinking really was to have some sort of template for prospective fundraisers
**\<gkruja>** maybe have 2 week sprints where the devs report there work so people know thats its being worked on actively even though the time frame is pushed back due to difficulties that could come up?
**\<tewinget>** "sprints" ...
**\<pero>** -\_-
**\<moneromooo>** You run if you want dude. I'm coding.
**\<tewinget>** gkruja, other than the term "sprints" which has a bit of a negative connotation from what I can tell, that doesn't seem like a bad idea.
**\<pero>** maybe 2 weeks isnt that bad to have it coincide with the dev meetings - but not all FFS work is dev wwork
**\<pero>** yea precisely tewinget
**\<fluffypony>** milestones are the reporting periods
**\<mattcode>** The Monero Enterprise Alliance needs to promote agility in the workplace, so we should all sprint every two weeks.
**\<fluffypony>** mattcode: hence the creation of MEAT
**\<tewinget>** we know how fluffypony loves his MEAT.
**\<pero>** well i typically insert checkpoints before milestones in projects
**\<fluffypony>** the problem with milestones is that they aren't always backed up by timeframes
**\<pero>** so i know if my milestones arent going to be hit
**\<pero>** and something can be actively done about it
**\<fluffypony>** pero: that might work, but might also be too formal, we need to balance it with it being accessible to part-time contributors
**\<hyc>** and what are our choices of things that can be done about it? Should we have a list of those spelled out?
**\<pero>** usually solutions arent that clear cut ;p
**\<pero>** might just be a matter of documenting a pattern of missed deadlines
**\<gkruja>** the progress updates could be determined on a per project basis
**\<endogenic>** better would be to list potential problems
**\<endogenic>** answers w/o the problems are sure not to match
**\* tewinget** runs and hides again
**\<pero>** ;p
**\<rehrar>** In my write up, the contract that was funded is the active contract, and if a change needs to be made for reasons then it needs to be brought before the community where the reasons for change and the proposed changes are brought up, and the community can decide whether it is acceptable or not.
**\<fluffypony>** rehrar: but then where's the forum for that? the dev meetings?
**\<rehrar>** Or community meeting
**\<rehrar>** Whichever is more appropriate
**\<rehrar>** Dev meeting for coding things, community for non-coders things
**\<pero>** well the missed deadline example is from 'real world' tewinget ... usually you need a documented pattern like that if you want to sever a contract and fire someone
**\<pero>** bring on a new resource/vendor
**\<fluffypony>** yeah true, I think the dev workgroup is better suited to analysing whether something is acceptable or not
**\<rehrar>** And as long as it's announced that a decision will be made in the upcoming meeting well beforehand, there should be no complaints that someone wasn't able to be present to vote.
**\<endogenic>** voting is a tricky concept
**\<moneromooo>** OTOH, decision ought to be in the hands of the donators for that particular project. Maybe I need to code some voting thing where one can prove they paid to a ffs...
**\<pero>** another thing with better defined scope/schedule/budget
**\<rehrar>** And that's a good point Moneromooo, should a person who didn't donate have any sway in the vote?
**\<pero>** is that we can manage what happens when 'contractors' go over budget
**\<pero>** tweinget and rehrar surely went much over what they estimated
**\<endogenic>** i don't think voting should be used, personally, unless it's limited to people who are actually qualified
**\<pero>** and unhappy resources are poorly performing resources from my experience
**\<rehrar>** I did?
**\<ArticMine>** Yes but should it be donators overall or donators to a specific FFS?
**\<iDunk>** When I donated to moneromooo's latest FFS, I was late and he was already funded. I donated anyway and wished I had a way to direct the donation to him anyway.
**\<ArticMine>** I mean we are putting general funds into these
**\<endogenic>** we only need to resort to voting in the absence of being able to determine what the problem actually is
**\<endogenic>** in any given case
**\<rehrar>** Can we vote via masternode?
**\<endogenic>** genius
**\<fluffypony>** lol
**\<moneromooo>** I didn't say anything becuse I am this biased, but Alice donating to Bob's clearly shows the intent.
**\<fluffypony>** soon™
**\<moneromooo>** \*thus
**\<pero>** so the FFS should have an ability or mechanism for the contractor to demonstrate a need for increased budget as well
**\<pero>** and the excess donations can be used partly for this 'contingency fund'
**\<endogenic>** one problem is that it will be difficult to achieve consensus on what the problem is if some people who are voting have an interest in people not agreeing that such a thing is a problem
**\<rehrar>** Maybe we can tackle this in Community Meeting too.
**\<endogenic>** so there needs to be some kind of standard about what is more important - maintaining those interests, or the solution to the actual problems
**\<fluffypony>** pero: increased budget = new proposal
**\<hyc>** dunno. as I see it, FFS means you pitch a flat rate for a project. Then how you manage your time is your own business, but there's no such thing as a budget overrun
**\<tewinget>** pero: on that note, I had trouble deciding originally for the zmq thing whether to do hourly milestones or progress milestones. I think requiring both might be a good idea. Either one can be the milestones for payouts, but the other should be tracked for progress as well imo.
**\<tewinget>** I'm just going off of "what would I do differently".
**\<moneromooo>** FTR, the kovri meeting is just starting too.
**\<hyc>** ah we need to wrap this up then
**\<gkruja>** if that's it then i can post my small gallery again for you guys and all the nice people on Reddit to see
**\<moneromooo>** I'll still be around in an hour :)
**\<moneromooo>** (to prod luigi, arf arf)
**\<endogenic>** see y'all again in 2 weeks?
**\<luigi1111>** making lunch :-)
**\<tewinget>** I'll be out cold in like 5 minutes. I'll update sometime tonight (well, tomorrow morning/early afternoon probably for you EU folks -- I seem to be on like GMT - 10 as far as sleep goes)
**\<fluffypony>** yup
**\<fluffypony>** two weeks™
**\<pero>** i think for defined deliverables, say like zmq
**\<pero>** just a scope table would go a long way in making it more manageable
**\<pero>** scope item | work effort | delivery eta
**\<dternyak>** moneromooo: OTOH, decision ought to be in the hands of the donators for that particular project. Maybe I need to code some voting thing where one can prove they paid to a ffs...
**\<dternyak>** I had a similar though, but then you run the risk of the vender funding a majority of their own FFS so that they could have majority vote on if they are fired.
**\<dternyak>** thought\*
**\<endogenic>** ^
**\<endogenic>** or any of many other possibilities
**\<moneromooo>** Interesting point.
**\<hyc>** if they're majority funder of their own project... what's the problem?
**\<endogenic>** they could crowd others out, for one
**\<moneromooo>** But then it'd be expensive and nobody would pitch in for the rest ?
**\<dternyak>** they can steal the other 49% of peoples money by never firing themselves
**\<endogenic>** even if they aren't hiring themselves, one group can still fund projects and make the same issue
**\<dternyak>** yes, there are several flaws
**\<endogenic>** and as for having people in general vote on stuff... has anyone heard of "bread and circuses?" it's commonly known that people tend to choose what's convenient or what might give them temporary gain even at the expense of future survival
**\<moneromooo>** Oh, anonimal's kovri.i2p mention made me remember a couple people said it'd be nice to have a hidden service (and eepsite) for Leading by example :)
\ No newline at end of file
layout: post
title: Logs for the Community Meeting Held on 2017-07-16
summary: Work groups and IRC channel reorganization, meeting structure, slogan, user guides, and miscellaneous
tags: [community, crypto]
author: dEBRUYNE / fluffypony