[GH-ISSUE #386] Why not combine the maintainer forces? #287

New issue

kerem · 2026-03-04T01:03:38+03:00

kerem commented

2026-03-04 01:03:38 +03:00

Originally created by @pre on GitHub (Jan 14, 2020).
Original GitHub issue: https://github.com/rivo/tview/issues/386

At the same time I'm both glad and sad to see this fork https://git.sr.ht/~tslocum/cview/

I'm glad because many significant improvements have been merged.
I'm sad because this is now a fork which will diverge both in philosophy and code.

The rationale behind the fork is explained in https://man.sr.ht/~tslocum/cview/FORK.md
It seems that the fork was motivated because the original author is/was maintaining this repository alone and didn't find the time to review all the good stuff pouring in.

Reviewing requires time and attention, but people who submit PRs are very often willing to change their implementation when they get a response. Problem is that reviewing has been only behind one person.

The problem is not resolved with the fork: now there's a diverged project which is again behind one person. The fork is not even in Github anymore.

Is there any chance to combine forces with @tslocum and @rivo ?

Shared projects have challenges of their own, but having multiple maintainers will drive the project further than one busy maintainer.

Personally I believe that the fork is a good discussion starter but it will not solve any problems in the long term.

Originally created by @pre on GitHub (Jan 14, 2020). Original GitHub issue: https://github.com/rivo/tview/issues/386 At the same time I'm both glad and sad to see this fork https://git.sr.ht/~tslocum/cview/ I'm glad because many significant improvements have been merged. I'm sad because this is now a fork which will diverge both in philosophy and code. The rationale behind the fork is explained in https://man.sr.ht/~tslocum/cview/FORK.md It seems that the fork was motivated because the original author is/was maintaining this repository alone and didn't find the time to review all the good stuff pouring in. Reviewing requires time and attention, but people who submit PRs are very often willing to change their implementation when they get a response. Problem is that reviewing has been only behind one person. The problem is not resolved with the fork: now there's a diverged project which is again behind one person. The fork is not even in Github anymore. Is there any chance to combine forces with @tslocum and @rivo ? Shared projects have challenges of their own, but having multiple maintainers will drive the project further than one busy maintainer. Personally I believe that the fork is a good discussion starter but it will not solve any problems in the long term.

kerem closed this issue

2026-03-04 01:03:38 +03:00

kerem commented

2026-03-04 01:03:39 +03:00

@rivo commented on GitHub (Jan 14, 2020):

I'm still taking care of tview but as you correctly noticed, it's not very fast due to the reasons mentioned. @tslocum's fork is basically tview but with all the PR's simply merged (I'm assuming no reviews or changes take place). I don't know if @tslocum is planning on putting time into working with contributors. E.g. I'm currently working with @millerlogic on mouse support (#363), I'm not sure if @tslocum is willing to fill such a role. (It would also require significant coordination — at least initially — between him and me.) And I'm certainly not going to blindly merge PR's into tview.

Generally, I'm open to getting help but I need to be sure that any such person understands tview and its programming philosophy and is not willing to sacrifice quality for the sake of quickly accepting a PR.

Until then, tview will evolve slowly but steadily.

@rivo commented on GitHub (Jan 14, 2020): I'm still taking care of `tview` but as you correctly noticed, it's not very fast due to the reasons mentioned. @tslocum's fork is basically `tview` but with all the PR's simply merged (I'm assuming no reviews or changes take place). I don't know if @tslocum is planning on putting time into working with contributors. E.g. I'm currently working with @millerlogic on mouse support (#363), I'm not sure if @tslocum is willing to fill such a role. (It would also require significant coordination — at least initially — between him and me.) And I'm certainly not going to blindly merge PR's into `tview`. Generally, I'm open to getting help but I need to be sure that any such person understands `tview` and its programming philosophy and is not willing to sacrifice quality for the sake of quickly accepting a PR. Until then, `tview` will evolve slowly but steadily.

kerem commented

2026-03-04 01:03:39 +03:00

@pre commented on GitHub (Jan 24, 2020):

I see that @tslocum attempts to drive the project forwards by doing. There are currently four recent and open Pull Requests by him waiting for review (ie. PRs don't have any comments).

I understand that there is a need to maintain control for the architectural integrity.

However - having the control behind one person, that is @rivo in this case, is a bottleneck for any project.

Personally, I believe that coding is doing but software engineering requires discussion.
I don't believe that a project can be driven by simply creating new PRs without discussion, and I don't believe that a fork solves that problem in any way. Rails and Merb community had this kind of dispute back in the days, and it was ultimately solved by these parties discussing and finding a new way of doing things.

What could be done for you two to discuss?

I would love to see this project moving forwards as a community effort instead of it stagnating under different forks.

@pre commented on GitHub (Jan 24, 2020): I see that @tslocum attempts to drive the project forwards by doing. There are currently four recent and open Pull Requests by him waiting for review (ie. PRs don't have any comments). I understand that there is a need to maintain control for the architectural integrity. However - having the control behind one person, that is @rivo in this case, is a bottleneck for any project. Personally, I believe that coding is _doing_ but software engineering requires _discussion_. I don't believe that a project can be driven by simply creating new PRs without discussion, and I don't believe that a fork solves that problem in any way. Rails and Merb community had this kind of dispute back in the days, and it was ultimately solved by these parties discussing and finding a new way of doing things. What could be done for you two to discuss? I would love to see this project moving forwards as a community effort instead of it stagnating under different forks.

kerem commented

2026-03-04 01:03:39 +03:00

@rivo commented on GitHub (Jan 24, 2020):

I'm not sure what to add to this. This is mainly a matter of how much time and effort someone can (and wants to) put into this project. I don't know anyone yet who is able and willing to fill that "software engineering" role you describe. Maybe @tslocum, who knows, but I haven't him say anything in this regard and simply accepting PRs is not the philosophy I'm looking for in this repo.

Again, I'm open to discussions with anybody who wants to fill such a role.

@rivo commented on GitHub (Jan 24, 2020): I'm not sure what to add to this. This is mainly a matter of how much time and effort someone can (and wants to) put into this project. I don't know anyone yet who is able and willing to fill that "software engineering" role you describe. Maybe @tslocum, who knows, but I haven't him say anything in this regard and simply accepting PRs is not the philosophy I'm looking for in this repo. Again, I'm open to discussions with anybody who wants to fill such a role.

kerem commented

2026-03-04 01:03:39 +03:00

@pre commented on GitHub (Feb 12, 2020):

Well, I was hoping that @tslocum would join the conversation.

@pre commented on GitHub (Feb 12, 2020): Well, I was hoping that @tslocum would join the conversation.

kerem commented

2026-03-04 01:03:39 +03:00

@sudormrfbin commented on GitHub (Mar 7, 2020):

https://git.sr.ht/~tslocum/cview/ now gives a 404 btw.

@sudormrfbin commented on GitHub (Mar 7, 2020): https://git.sr.ht/~tslocum/cview/ now gives a 404 btw.

kerem commented

2026-03-04 01:03:39 +03:00

@tslocum commented on GitHub (Mar 11, 2020):

Thanks @gokulsoumya, I moved my projects to GitLab. Please find cview here.

As explained in FORK.md, the motivation behind cview is to further the development of the tview/cview ecosystem by increasing maintainers due to the lack of original maintainer activity. I would speculate that cview's existence is at least partly responsible for the increased activity from @rivo on tview. This might be entirely coincidental. I am glad to say that the issue of pull requests not being reviewed/merged is less relevant now, but may become relevant again.

I disagree with some of the design/engineering decisions made in tview and plan on exploring new ideas/solutions in cview. tview isn't better or worse in this way, it just doesn't fit what I am looking for entirely. For instance, in issue #411, @rivo explains an engineering decision made in tview to popagate sizes in one direction. I would like to explore propagating sizes in both directions in cview. @nojus297 has submitted a proof of concept I hope to expand upon.

Because I always submit changes upstream, these projects are enjoying a symbiotic relationship, and should not be viewed as competitors.

@tslocum commented on GitHub (Mar 11, 2020): Thanks @gokulsoumya, I moved my projects to GitLab. Please find cview [here](https://gitlab.com/tslocum/cview). As explained in [FORK.md](https://gitlab.com/tslocum/cview/-/blob/master/FORK.md), the motivation behind cview is to further the development of the tview/cview ecosystem by increasing maintainers due to the lack of original maintainer activity. I would speculate that cview's existence is at least partly responsible for the increased activity from @rivo on tview. This might be entirely coincidental. I am glad to say that the issue of pull requests not being reviewed/merged is less relevant now, but may become relevant again. I disagree with some of the design/engineering decisions made in tview and plan on exploring new ideas/solutions in cview. tview isn't better or worse in this way, it just doesn't fit what I am looking for entirely. For instance, in issue #411, @rivo explains an engineering decision made in tview to popagate sizes in one direction. I would like to explore propagating sizes in both directions in cview. @nojus297 has submitted a proof of concept I hope to expand upon. Because I always submit changes upstream, these projects are enjoying a symbiotic relationship, and should not be viewed as competitors.

kerem referenced this issue

2026-03-04 01:08:27 +03:00

[PR #287] [CLOSED] Added GetFormItems() #896

kerem referenced this issue

2026-03-04 01:08:29 +03:00

[PR #298] [CLOSED] Added GetFormItems() #902

Sign in to join this conversation.