@xuhcc, we had a great chat about all this on the weekly call Discord yesterday. Here are the notes.
Would you be open to jumping on a call, even if you’re just listening and typing back, so we can try to get to an agreeable place on how to move forward?
Thanks for the invitation, but I’m not interested. I think I already expressed my position clearly and I know yours. To reiterate:
Also, who are these people on the call? If they want to talk with me, why don’t they come here and introduce themselves?
Hey @xuhcc @auryn - chiming in on the suggestion to chat, above.
Auryn and I met through a friend, talking about clrfund and the possibility of me contributing to the codebase, given the indication that there’d be less time for contributions in the repo moving forwards.
As I understand it, discussions and plans that happened synchronously have not been re-communicated asynchronously - like to Telegram or this forum. I suggested that we (@xuhcc @auryn and myself) could talk synchronously (in audio or real time text), as a way to find a path forwards for useful contributions in ETH2CLR to benefit clrfund.
Responding to your points in my limited understanding from (alas, synchronous) chats with Auryn:
@xuhcc - do you think collaboration can continue if the above changes are made and “clrfund remains clrfund”? The UI/looks/theme/branding disagreements could be resolved by forks that only slightly diverge, for example a @xuhcc/clrfund fork that disables new components you don’t want to use.
That way ETH2CLR and @xuhcc/clrfund could remain different, while easily pulling new stuff upstream from clrfund. At the same time it would let clrfund be useful for the maximum amount of new users moving forwards.
Hi @codeluggage ,
Yes, we talked about merging back useful changes, but it was long time ago. Since then the webapp architecture, page layout and the user flow have changed significantly. So unless you consider all changes useful (I think most of them aren’t), extracting individual features will be very difficult. It would be easier to re-implement good ideas from ETH2CLR fork on the main codebase than to deal with this huge diff.
I don’t see why the path towards customizable theming/branding can’t begin with main clrfund codebase. In fact, I think that will be easier. You can look at the comparison between reference UI and EthDenver custom UI to see how it’s done.
If that means to replace main codebase with ETH2CLR and change the logo, then no, I won’t support that.
If you want to chat about technical aspects of clrfund, feel free to DM me. But I think all important decisions should be discussed publicly. In the past we mostly used forum for that purpose, but now discussions moved to private telegram chats and discord calls. That’s unfortunate.
This is a great point. I would definitely like to steer more discussion back toward the forum so it’s easier for people to keep track of things async. That said, there are definitely times when calls or synchronous chats make sense. So in those cases I think we should make an effort to post notes back to the forum so there is a more definitive log of the activity.
We recently created this notion space to keep track of meeting notes. But perhaps it makes sense to port this back to the forum.
That’s a super nasty diff. +1 on feature branches, this kind of PR would be turned down anywhere, just refactor it and submit again (happy to help)? It’s a painful error but usually one you only make once.
To move the conversation forward productively, maybe we can request contributors to use feature branches in contributor guidelines- this way a release with any combination of features can be cut over which seems to really be the crux of the issue here.
@xuhcc we could also add ways to address any of your other concerns to the guidelines before a contributor can request a code review for a PR into one of the repos? (This is a reasonable way to be mindful of everyone’s time and output better code)
What ever the standard set it ought to be transparent.
In case of backporting, we should first decide what features should be ported from ETH2CLR fork. For example, I think a landing page would be useful.
For some features (like landing page), it could be easier to re-implement them from scratch than to refactor existing code.
When ETH2CLR team wanted to contribute to the main codebase, they did use feature branches (1, 2). The issue here is that frontend changes were never intended to be merged back.
But I agree that contributor guidelines could help in the future. Specifically, I would ask contributors to create an issue and describe the problem they are trying to solve before submitting a pull request.
they did use feature branches (1 , 2 ).
Actually these look great, (and are merged). I’ll draft contributor guidelines this week and send out here for feedback so we can get something basic up.
In the meantime @codeluggage @samajammin please refactor the PR into a few feature branches and create an issue with the user story you’re going for (I’m sure you have this written up already elsewhere anyway). I don’t really care about the implementation details- if they cherry pick commits into new branches or reimplement shouldn’t matter. It sounds like the features ought to have been: cart changes, connection modal, linter stuff, landing page, and what ever they mentioned that does custom theming at a higher level, then probably a ‘tweaks branch’ which I agree will likely not be merged back in.
This sound like a reasonable path forward for everyone?
Yeah, that sounds reasonable to me.
First stab at contributor guidelines:
CONTRIBUTING.md
It’s open edit at the moment, so anyone is free to chime in (be civil please). Will leave it up for the next few days.
Overall looks good. Perhaps it should be shorter, otherwise new contributors may decide to skip it.
Shortened by 25%. 
Left a few minor comments. Looks good!
Awesome. Leaving it open for the next seven days as we get more feedback then will circle back here.
Hey all - thank you for the thoughtful discussion here.
(Apologies for this late reply - I stepped away for almost 2 weeks for a family vacation)
I’d like to weigh in from my perspective (not necessarily that of the Eth2 CLR team or the EF more broadly). For context on who I am… I’ve been the lead developer from the EF on the Eth2 CLR side of things. I was not originally the EF project lead on this initiative when we kicked things off months ago but I’ve since transitioned into that role over the last month.
In hindsight, there’s many things I would have liked for us to do differently on this project. I feel bad about how things have turned out. Primarily @xuhcc - I feel like we’ve mistreated you. You’ve clearly been instrumental in the development of this project. If we could start this over, I would have changed how we approached our collaboration in order to get you more involved in the design & product decisions. You’ve been extremely helpful every time I’ve reached out to you.
I think this happened for 2 primary reasons:
Regarding this 1st reason, from the start we made a group decision on calls & in the Telegram group chat (with clr.fund team members involved) to fork the codebase with the understanding we would attempt to merge our changes upstream to the monorepo (only if you folks found those changes useful). We attempted to & successfully did merge some changes in via feature branch PRs (as you pointed out) but as the project progressed we started to realize:
We did communicate these concerns to @auryn & @spengrah on calls but we should have done a better job communicating these decisions publicly & asynchronously. For that I apologize & as the new project lead on the Eth2 CLR project, I will try to do a better job on this moving forward.
Regarding the 2nd reason, I think this assumption was an unfair mistake, as we should recognize that time zone & language differences can make synchronous communication a challenge. I agree a more ideal approach would be to move discussion back to public venues like this forum, so that decisions from those conversations aren’t lost. We were also hesitant to ask too much of you. I regret not asking you directly upfront about your interest in potentially collaborating on design & product feature decisions (although we did request input many times in the group Telegram).
Moving forward…
While our team is on the hook to deliver this standalone Eth2 CLR instance within the next couple months, we still want to help! We want to support clr.fund & contribute to this project where you folks think it makes sense. Our goal here is not to maintain a separate fork. This is a one-off project with the intention of merging any improvements back to the monorepo. Our goal was not to completely replace the UI - we’ve tried to build off & supplement the existing great work you’ve created. We are not looking to force our changes into the canonical instance in anyway.
I agree, our fork has begun to diverge quite drastically to the point where merging it would be a gnarly undertaking. I agree with @xuhcc that the best approach at this point may be to cherry-pick individual features / pages / components that we’ve created. I agree this is certainly not ideal as it requires additional work vs. if we had created clean PRs from the start but as I mentioned, it just didn’t seem achievable given constraints. I’m still optimistic there’s aspects we can bring back into the monorepo without causing major pain or conflict.
It’s definitely been a learning experience figuring out how to best manage this project given all the various stakeholders (both within the EF & the clr.fund team). I’m open to any feedback folks have on how we could have done better & how we can improve things moving forward as we approach our Eth2 CLR launch.
Hello, thank you for writing that.
I didn’t participate in design discussions because we were working on separate projects. I didn’t think it was appropriate for me to interfere with your work, and I was too busy with clrfund development anyway. So in this context, your assumption was correct.
But now everyone is saying that from the beginning the intention was to merge all changes back. This is a big news for me. And raises even more questions. Given that I was the solo developer of clrfund and maintainer of the codebase, why this decision was kept secret from me? Why didn’t anyone ask me about that in the first place?
Actually, this is not the first time such thing happens. When I only started working on this project, Auryn & Spencer suddenly decided to hire developers from RaidGuild to rewrite the code I contributed. I learned about that decision only when people started to submit pull requests. Sounds familiar? 
However, that “collaboration” ultimately failed and I continued to work on clrfund.
I’m not sure to whom you are referring here, but I heard that @daodesigner wanted to make some cosmetic changes to your fork and split the monorepo into two parts (see this post – Should the subgraph be added to the monorepo?). I’m not involved in this initiative. And I’m not associated anymore with the “canonical” clrfund instance at https://clr.fund.
The original clrfund currently stays at clrfund/monorepo and I’m not planning to replace the original UI. The backup will be kept at my repo. If you’re interested in contributing to it, let me know. But I guess the best way forward for you is to continue working on your fork.
As @xuhcc said, I’m taking point in splitting the monorepo, while preserving the original code. We’re growing quickly and seems we need a new kitchen for our chefs. The monorepo is a good place to fork from for now, in the future, goal is to be able to deploy clr.fund instances via a mechanism similar to daohaus. We now have circuits that scale to millions of users, are deploying Arbitrium test rounds to address gas concerns, and a shiny UX thanks to the EF. The truth is the project today is very different from what it was 6 months or a year ago, and we’re happy for everyone that’s been along for the ride 
. Change is good!
If he doesn’t continue to contribute, opinions are not so important
