Skip to content

Latest commit

 

History

History
412 lines (215 loc) · 16.9 KB

2022-09-13-community-meeting-notes.md

File metadata and controls

412 lines (215 loc) · 16.9 KB

Community Meeting Notes September 13, 2022

Community Council (CC) meeting held @ 15:00 UTC in grincoin#general channel on Keybase. Meeting lasted 59 min.

Notes are truncated, and conversations sorted based on topic and not always chronological. Quotes are edited for brevity and clarity, and not always exact.

Community attendance:

  • dtavarez
  • cekickafa
  • defistaker
  • yeastplume
  • deeev
  • renzokuken
  • phyro
  • anynomous
  • vegycslol

Short Summary

  • Biweekly Meeting schedule affirmed.
  • Bounty amount for writing a CFFI wrapper of secp256k1-zkp fork has been discussed.
  • Retroactive Grants like idea proposal has been discussed.

Agenda Points & Actions

dtavarez : @cekickafa would mind to introduce the first item of the agenda?

cekickafa :

1) Community Biweekly meeting Schedule

anynomous : Regarding this topic, you mean to discuss if the scheduled times are still convenient for others or if we should change times?

cekickafa : well, as phyro said before, if someone want to engage to meetings, can request,propose a time. Else, schedule looks fine.

anynomous : I know that for the CC members these times are convenient. One of us prefers the 10:00 UTC time, for the other members, both times work out. One of the difficulties is that if community members would not find these times convenient, we would not find out easily, because they wont be here to discuss it.Let me ask for everyone present here. Do the current times 10:00 and 15:00 UTC work for you?

dtavarez : I prefer this time.I am OK with this time.

cekickafa : i am OK also

anynomous : Same here

defistaker : Same

anynomous : @phyro @deeev Do the current meeting times, 10:00 and 15:00 UTC work for you?

👍 phyro, deeev

deeev : Perfect.

dtavarez : My suggestion is to set all the meetings at the same time (this time), and we let one day open for change.

👍 cekickafa, defistaker

deeev : just wondering for people in the US, would be tricky.

anynomous 👍

anynomous : Perfect. In that case I think we should take a passive approach, if anyone has a problem with these times or want to discuss a topic at another time, they are welcome to suggest so. But without specific notice we keep these times.

👍 cekickafa, defistaker, phyro ,dtavarez, deeev.

2) Bounty for writing a CFFI wrapper of secp256k1-zkp fork

(https://forum.grin.mw/requesting-help-with-writing-a-cffi-wrapper-of-our-secp256k1-zkp-fork/10024 )

anynomous : I discussed this with @dtavarez . I find it hard to estimate, but for now we got to an estimate of 10-20k in euro as bounty for the wrapper. Conditions are, open source (Apache or MIT), well documented and sufficient test cases for the wrapper. @renzokuken propose making the bounty extendible. For that reason we thought 10k as a basis might be enough, extending to 20k if it can with sufficient argumentation be shown that additional time and work was needed. ☝️ Just a rough estimate, so feedback is welcome, especially from developers.

phyro : https://github.com/rustyrussell/secp256k1-py

dtavarez 👍

renzokuken : Thank you. I have some remarks: 1. It has to be MIT licence because the wrapped library is under MIT. 2. I think 10K EUR is quite a lot given then I just need someone to find how to run the build with missing methods and I will handle the rest of the work (wrapping them, making into a module etc)

dtavarez 👍

phyro: https://github.com/rustyrussell/secp256k1-py

In the read me of my repo there is same link as an example, I used it as template while working on it.

phyro 👍

dtavarez :

phyro: https://github.com/rustyrussell/secp256k1-py

maybe that can be forked.

renzokuken :

dtavarez : maybe that can be forked.

This does not have zkp methods, no commitments, no range proofs etc, just basic secp256k1

deeev : Lets have as base currency $. Euro will likely continue to go down. However, i'd say we start with 3k$ for any significant progress. And we let renzo judge if the work provided is enough for him.

renzokuken, dtavrez,anonymous, cekickafa 👍

renzokuken : Yes I think $3K is reasonable.

anynomous : Sounds good to me. If no one takes the bait, we can always reconsider and go up with our bounty.

deeev : I dont much like bounty itself and to lock it for a single person.

anynomous : I can imagine thought, that someone who takes the bounty also would like an estimate of the complete finished wrapper, how much? 6k? I think locking itself is not a problem, as long as we put a deadline on the lock. E.g. show significant progress within 3 months. Again, just my estimate, so feedback is welcome.

renzokuken : I think once it builds making it into a wrapper is quite simple. But preparing some examples and docs could take a while

anonymous 💯

anynomous : I think documentation and testing takes most of the time actually.

renzokuken : Agreed.

anynomous : Ok, everyone agrees, thumbs up for 3k for some real progress, total bounty is still hanging though, 5k?

dtavarez : let's do not underestimate the repo is quite big *Graphic

defistaker : I think 3k-10k is generous, it should attract developers.

dtavarez : 25k lines of code is not a joke.

anynomous : Ok, I think 10k is manageable considering its worth. So 3k for showing significant progress, 10k $ total.

defistaker 👍

dtavarez : 3k to 10k sounds good to me.

anynomous :

dtavarez : 25k lines of code is not a joke.

True, but most of that is C, so not actually added work.

renzokuken :

dtavarez : let's do not underestimate the repo is quite big *Graphic

Which repo is it?

deeev : Libsecp zkp

anynomous : I think the non C code is about 10%, so 3000 lines of code and documentation.

dtavarez :

renzokuken : Which repo is it?

https://github.com/mimblewimble/secp256k1-zkp

renzokuken :

anynomous : True, but most of that is C, so not actually added work.

Yes and CFFI lib handles most of the work, this bounty is a clever copy paste for someone who knows how to compile C code.

anynomous 👍

I think if someone knows how to handle header files and knows which files to exclude and what definitions to copy from secp256k1-py this bounty is super trivial.

anynomous : Ok, lets vote. Everyone in favor of 3000$ for significant progress, 10.000$ total bounty.Requirements, MIT licence with good taste cases and documentation.

renzokuken : Just for me it’s a trial and error as I have no experience with that

deeev : However, if a person interested by this work want more. We could increase. What I like to do in these case would be just say to renzo, judge the work and reward accordingly. The cc can say we give a range of 3-5k.

renzokuken, dtavarez 👍

phyro : it's possible that once we upgrade our libsecp fork someone will have to upgrade this.

renzokuken 👍

deeev :

phyro : it's possible that once we upgrade our libsecp fork someone will have to upgrade this.

True.

anynomous : Probably that would mean minimal changes though, only the C under the hood should change right? We should have access to the original repo though.

phyro : and when we upgrade, perhaps the linked py ffi would almost match and could be used completely and be extended. Idk really, just something to keep in mind.

renzokuken 👍

renzokuken : If that situation occurs I will 1. Try to make new build with update repo 2. If fails automatically I would try to fix myself 3. If that fails I would ask for help again.

deeev 👍

dtavarez :

renzokuken : If that situation occurs I will 1. Try to make new build with update repo 2. If fails automatically I would try to fix myself 3. If that fails I would ask for help again.

could you transfer the repo to grincc? we could give you write permissions.

renzokuken : Of course.I will remove donation information from the readme first.

dtavarez, deeev 👍

Noticed php and js cffi wrappers work similar to Python so maybe deps.c file could help us kill 3 birds with one stone.

dtavarez : can we move to the next topic:

deeev, anonymous, cekickafa, renzokuken 👍

3) Retroactive Grants like idea

(https://blog.opengsn.org/taking-retroactive-grants-from-concept-to-practice-at-gitcoin-grants-round-11-649497d08519)

dtavarez : Retroactive grants in summary;

I would like to suggest Retroactive Grants. People can nominate themselves or dominate another person on the basis of contributions made. I do not have the process clear yet but that is the basic concept. The objective is to recognize the impact that the contributions from community members have made on the Grin ecosystem. one quick example could be @nicolasflamel1 and the hardware wallet implementation, if the code can be reviewed, audited and improved I do not see why not to donate or @renzokuken with grinventions would be another example I have more examples in my mind, but that the idea, if we agree that it could be something objectively good for Grin we could come up with a formal proposal.

deeev : I'm all for it.

defistaker : I support this suggestion.

renzokuken : The community council could go through community nominations, review what was done and attribute a prize.

dtavarez : correct.

cekickafa : Thats a good idea.

dtavarez : i know,right.

deeev : Actually for nicolas flamel, i dont see the need of retroactive grant needed since there's already a bounty on this.

renzokuken : Non-technical people could also be nominated. For blogging, making videos, organizing events etc.

deeev :

renzokuken : Non-technical people could also be nominated. For blogging, making videos, organizing events etc.

I quite like that as well.

anynomous : I think the idea has merit, not sure about the details yet. In general, if everyone thinks someone deserves a bounty retroactively, it should be no problem.

dtavarez :

deeev : Actually for nicolas flamel, i dont see the need of retroactive grant needed since there's already a bounty on this.

yep but he should go through the constrains though to get the bounty.

deeev : Even if its still 20$ for a video. That may still be highly appreciated from the maker.

anynomous : Only problem I have is that I think we should not create expectation that everything will get paid. Volunteer work should be there.

dtavarez 👍

renzokuken :

deeev : Even if its still 20$ for a video. That may still be highly appreciated from the maker.

Many YouTubers don’t even get that.

deeev : Based on contribution and community willing. I agree that contribution should always be rewarded.

renzokuken : Even a single tweet could be rewarded if makes an impact.

deeev :

dtavarez : yep but he should go through the constrains though to get the bounty.

Which constraint?

dtavarez :

deeev : Which constraint?

https://forum.grin.mw/t/locked-support-ledger-wallet/8517

deeev :

renzokuken : Even a single tweet could be rewarded if makes an impact.

Community willing. What i like to do usually is to reward someone that did something and did not asked anything in return.

renzokuken 👍

renzokuken : I remember when I joined in I used to bitch a lot about website, I didn’t realize I could PR to repo to suggest changes and now such people could be rewarded for making an initiative.

anynomous : Mmm. I am divided. I like incentives, but I hate creating expectations.

celickafa : Grin itself is an expectation somehow :)

renzokuken : We could steal the review process from other organization ;)

deeev :

anynomous : Mmm. I am divided. I like incentives, but I hate creating expectations.

That's why. I'm saying just reward people when they did something and asked nothing in return. Just like a gift.

dtavarez : but it is still retroactive and proposed by the community members themselves.

phyro : we have very few people contributing for free today (actually, it's increasing now). I'd try to get as many contribute for free without expectations or hopes they may get something.

deeev, anonymous 👍

dtavarez : if the community understand someone is adding value should be taken into consideration.

renzokuken : This also resolves the problem of estimating how much a challenge is worth. Hard to predict the efforts needed but post-factum everything is clear.

dtavarez :

phyro : we have very few people contributing for free today (actually, it's increasing now). I'd try to get as many contribute for free without expectations or hopes they may get something.

yes, and I do understand that I do not disagree but what we could do is to be open to support contributors.

phyro : contributors with a good record gain community trust and are more likely to get their next request approved.

deeev, anynomous 👍

Also explaining why B got it and not A and C might make A and C feel bad about their contributions in the sense that the community does not appreciate their effort enough.

anynomous : I think these free 'bonusses' are ok. But only for small amounts. For larger contributions, why not let people create a Funding Request (I know it creates a hurdle), but they could always say, please pay me afterward what you think it is worth.

dtavarez : I think we all agree on that the lack of man-power is no good for grin, right?

deeev : Agree on that.

phyro 👍

anynomous : I think we all agree on that, the danger is really that incentivising one as a suprise might feel like a disincentivize to another, the examples @phyro gave.

dtavarez : True.

cekickafa : if different approach will bring man power, better worth a try.

deeev : But giving grant does not mean we'll have more contributors. We re lucky on the fact that someone gave 100 btc. But those are limited and we should be careful to not be so generous at the same time.

phyro : it's a bit of a social problem really. I think good contributors will come because they like the tech, just like everyone else before them that came :)

anynomous : Hence, I think this idea is fine, but we should limit it, only fun bonusses, but then again that is rather close the bounty system we have, people can justs propose to add their work as small bounty.

deeev : If we start by granting people and we'll not have more funding on the future, we could count only on contributors.

anynomous : How about we agree to keep it only small amounts, so pocket money? Anything large would be an exception, funding request or a request to create an additional bounty.

👍 deeev

deeev : Lets stimulate community members while at the same time endorsing the spirit of free decentralised work out of the love for the project.

phyro : this too orders contributions by importance.

anynomous : @phyro so what is your final verdict/opinion, just not do it and keep the current system?

dtavarez : I would like to give it more thought based on the feedback received. if you don't mind and move the conversation to the forum.

👍 deeev

phyro :

anynomous : @phyro so what is your final verdict/opinion, just not do it and keep the current system?

idk, I don't really want to influence the decision.

dtavarez : is that OK?

phyro : idk, I don't really want to influence the decision.

all opinions influence the decision.

anynomous : Same here, I need to think this through more as well. I think it would require some forum discussion. In general I like that reputation of doing work for free just give you trust, hence more easy to create a funding request or request a bounty. But again, we need more feedback on this.

deeev : Let's move that conv to the forum.

👍 dtavarez

anynomous : And all opinions are welcome, we all are just community members here, council members of one council or another are no exception, they just collect opinions and cast their final votes accordingly for proposals but they are free to express their opinions.

cekickafa : Forum or keybase, it should be discussed more broader than a meeting time. It is important and vital for Grin future.

dtavarez : I will open a forum post. I think there are valid points here.

👍 cekickafa, anynomous.

anynomous : Ok, that is the descission for today, I think it is clear that there are ups and downs and that more feedback is needed. So that is it for today, that wraps up the meeting? Anything else that needs to be discussed or added to the next meetings agenda?

dtavarez : that's for today. 3 topics in 1 hour, record time!

Action points

  • Community meeting schedule stays same.
  • Bounty for writing a CFFI wrapper of secp256k1-zkp fork idea accepted.
  • Retroactive Grants like idea will be discussed more.

Meeting adjourned.