Who should decide what PRs to merge and how to resolve disputes?

Shortened by 25%. :scissors:

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.

2 Likes

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:

  1. I believe our team has been placed in a difficult position of both aiming to deliver a standalone Eth2 CLR product quickly while also aiming to contribute to the clr.fund canonical instance.
  2. I suppose we made the incorrect assumption that you (@xuhcc) were not interested in directly contributing given your lack of participation on calls, Discord server chats & lack of feedback in any of the Figma designs & Notion docs we shared via Telegram.

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:

  1. We needed to move faster given the aggressive deadlines placed on our team. Getting both our teams to align on features/UI/content changes as well as review every change via independent PRs inevitably slows development times. We made the decision to prioritize getting features merged for our Eth2 round needs first & foremost, while considering merging changes into the canonical CLR.fund instance later (which Auryn & Spencer both supported).
  2. Certain aspects of our Eth2 CLR instance (e.g. functionality around the optimistic recipient registry, the ability to rely on only one funding round existing, dedicated landing pages to Eth2 CLR content) are unique to our project & likely don’t make sense for us to merge back into the monorepo.

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.

6 Likes

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? :slight_smile: 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 :blush:. Change is good!

2 Likes

If he doesn’t continue to contribute, opinions are not so important