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