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

general
#5

@spengrah It depends on what you mean by “actively maintain”. I will continue to maintain the codebase. But that doesn’t mean that I have to implement requested features or accept every pull request.

@auryn No idea why you’re talking like I’m obligated to work on features or communicate with anyone. I’m volunteering to work on this project and I don’t work for you or Ethereum Foundation. Nevertheless, I was responding to people on Github and in ETH2CLR chat. What you’re saying is not true.

No idea why and how I was expected to participate in the development of ETH2 grants. It was a separate instance of clrfund with the goal of funding ETH2 development, with a dedicated team working on it. Nevertheless, I cooperated with them, by answering their questions and helping navigate the code. We talked about porting useful features back to main clrfund repo, but no one ever mentioned that ETH2CLR frontend will replace the original clrfund UI. And now it’s somehow “not a separate project”. LOL

#6

For everyone else reading this thread:
I’ve been working on clrfund for more than a year and helped launch the first several rounds, but apparently this is coming to an end. I don’t support the aforementioned “merge” and, more generally, I don’t like where this project is heading. But it doesn’t seem that I’ll be able to change anything here, certainly not in the long term. The original codebase will be preserved at https://github.com/xuhcc/clrfund. If you’re are interested in using it or contributing to it, please let me know. Maybe I’ll be able to help.

#7

I did not imply that you are obligated to do anything nor that you work for me or the EF.
Simply that from my perspective, and from what you’ve communicated to me in DMs, it seems as if you are no longer actively maintaining the repo.
However, I do very much appreciate the fact that you’ve still been responding on Github and in the ETH2CLR chat.

There was no expectation that you would. But that was your choice.
Yes, it is intended to be deployed as a separate instance. However, the intent has always been for the work to be merged back upstream if and when it makes sense to do so.

I agree, no one said it would wholesale replace the current UI. Quite the opposite. We’ve talked about merging changes that we liked and that would be useful to roll back into the main repo. Those changes, along with the deployer that @spengrah and Q have been working on are intended to push the main repo toward a point where it’s more easily re-usable by anyone who wants to host their own instance of clrfund.

Could you be more specific about what you dislike about where the project is heading?

And what makes think you won’t be able to change anything? I don’t recall you raising any concerns like this previously. In fact, when I’ve explicitly asked you about why you’re not working on new features and if anything has changed, you simply said “I have other stuff to do” and “nope”.

If there are things you disagree with or that you would like to change, then we should have a discussion about it. I, and everyone else here, have a great deal of respect for your opinion and the work you’ve done. So if you do have an issue with something, then let’s find a way to resolve it.

1 Like
#8

@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?

#9

Thanks for the invitation, but I’m not interested. I think I already expressed my position clearly and I know yours. To reiterate:

  • I’m continuing to maintain the codebase. I don’t know anyone with the necessary knowledge to whom I can delegate this task.
  • That doesn’t mean that I will work on new features (actually, I don’t remember anyone asking me about any particaular features lately, so I don’t know why this came up).
  • ETH2CLR is a separate project. It was being developed independently for several months, they never asked me to work with them or review their code, and I was not aware of any plans to replace original clrfund UI with theirs until recently.
  • I think original clrfund UI is superior and I don’t want to throw it away.
  • If you decide to replace the original codebase with ETH2CLR fork or lock me out of the main repo, I will maintain the code in another repo (if there’s a demand for that, obviously).

Also, who are these people on the call? If they want to talk with me, why don’t they come here and introduce themselves?

#10

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:

  • Yes, I don’t know of anyone you could delegate that to, but I’d love to help.
  • New features/upcoming work that I’m aware of is listed in https://github.com/clrfund/monorepo/issues, though more may be floating around the memories of those who’ve been in synchronous discussions.
  • ETH2CLR does seem like a separate project without the context from synchronous discussions, but the intention was to merge useful changes back to clrfund - while “keeping clrfund as clrfund”. Specific changes in ETH2CLR that don’t fit into clrfund would not make sense to merge back.
  • The clrfund UI/looks/theme/branding will not be thrown away. Rather, by adding the work done in ETH2CLR we could begin a path towards customizable theming/branding so new users can tweak it to fit their project.
  • Ideally, beginning a new branch to process the ETH2CLR changes, updating the changes to retain the clrfund UI/looks/theme/branding while adding what’s useful, would make clrfund better.

@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.

1 Like
#11

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.

1 Like
#12

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.

1 Like
#13

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.

#14

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.

3 Likes
#15

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.

image
image1150×1524 122 KB

#16

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.

2 Likes
#17

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?

2 Likes
#18

Yeah, that sounds reasonable to me.

#19

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.

#20

Overall looks good. Perhaps it should be shorter, otherwise new contributors may decide to skip it.

#21

Shortened by 25%. :scissors:

#22

Left a few minor comments. Looks good!

#23

Awesome. Leaving it open for the next seven days as we get more feedback then will circle back here.

2 Likes
#24

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