The PR seemed reasonable to me, since it was intended to improve the developer experience for the current and new contributors, and seemed to have support from the ETH2 team (who are currently doing the most active development on clr.fund). However, @xuhcc (who has been the primary driving force for clrfund development until recently) voiced a strong opposition to the PR due to a personal preference for tooling that does not make automatic changes to code.
So my question is, since @xuhcc has indicated that they are no longer actively contributing to clrfund, should collective decisions still be made to suit their preferences? Or should we prefer outcomes that improve the developer experience for others that are stepping in to fill that void?
Iâm still maintaining the main clrfund repo and therefore Iâm deciding what PRs to merge. There are simply no other contributors who know the project well enough to make informed decisions on PRs. In addition, the PR in question is not an objective improvement, itâs just a change to the tooling and its value depends on the preferences of a particular developer. I think people with no history of previous contributions donât have a say in this matter.
ETH2 team (who are currently doing the most active development on clr.fund)
Thatâs not true. EF team is working on a fork, which diverged significantly from the original clrfund codebase. As far as I know they completely redesigned the UI. I did not participate in that redesign nor did I review any changes they made to their fork. So itâs a separate project by now.
There is sometalk about merging everything back into clrfund-main, but I donât see a way to do that unless they somehow split their changes into smaller reviewable parts. Also, I donât think their UI is better than the reference clrfund UI (although they implemented some good ideas).
I think the main issue at hand is resolving these two observations.
@xuhcc, all else equal, would you prefer toâŚ
A) continue to actively maintain the clrfund monorepo, or
B) no longer contribute to clrfund, or
C) something else?
If (B), then for @xuhcc to step away we need to address the lack of additional contributors. To the extent that (and I make no judgement about whether this is the case) supporting the tooling preferences of would-be additional contributors makes it more likely for them to contribute and develop the the knowledge necessary to maintain the project in @xuhccâs absence, I would propose that we do so.
Are you though? You last commit was 28 days ago and youâve indicated in DMs that you are ânot actively working on clrfund anymoreâ and âI donât work on new featuresâ.
If you are maintaining the repo, then we need to re-establish communication because itâs been short or non-existent for the last month.
I agree. Youâve been the primary driving force behind clrfund for the last year. But we now have new contributors looking to join, which should hopefully spread some of the burden that youâve been carrying solo.
Iâd really like to ensure that these new contributors feel comfortable and empowered to make suggestions and contributions. Especially if you are no longer actively working on clrfund.
I wholeheartedly disagree. Yes, I think that people with a proven contribution history should have more of a say, but just because someone has not yet contributed does not mean their opinion is not valuable.
Youâve chosen not to participate in this, even though youâve been part of the telegram group where the vast majority of that discussion happened. From day 1, one of the goals of this work was to merge changes back upstream. It is not a separate project.
Thatâs fair. At this point it will probably be a significant effort to merge the changes. Nevertheless, I think itâs a worthwhile effort. Iâd suggest that perhaps this is something that Matias can take on. Merging into a new branch in clrfund/monorepo and once the styling and functionality is inline with what we can for the canonical instance, then merging it to develop.
Also fair. Theyâve gone ahead and implemented it on the ETH2 fork for the time being.
@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
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.
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.
@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:
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?
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.
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.
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?
