This Project has no future!

[Thomas De Schampheleire]

Hi Dominik,

2018-04-09 20:08 GMT+02:00 Dominik Ruf <dominikruf at gmail.com>:
> Hi all,
>
> I was in denial in the past years. But it is time to face the facts. This
> project isn't going anywhere.
> About a year ago I already expressed my worries, but next to nothing has
> changed since. There are still pull requests that are multiple years old.
>
> For example, my bootstrap PR is still not pulled completely. There is still
> a discussion about whether (and how) we should use minification and source
> maps.
> These are technologies that practically every web application in the world
> are using. So this should be a no-brainer. And yet, after more then 2 years
> we discuss if adding the source map flag should be in a separat changeset.
> Seriously guys, this could be in the dictionary as the very definition of
> bikeshedding.

I'm sorry you feel this way.

I don't agree that the project is not going anywhere or it has no future.
It's just so that at this moment the pace of development is quite slow
because we are near the end of the bootstrap PR, and there are some
changesets where there is still a discussion. It is not so much about
whether or not to use minification or source maps. There was some
unclarity on how the source map actually works and whether the feature
was complete, that is clear to me now.
There is also an open point about the 'watch' feature and whether or
not it should be integrated in gearbox --reload rather than
introducing a new 'nodemon' mechanism.
The introduction of 'npm run X' has also raised some comments in the
past regarding cross-platform support. These is IMHO not bikeshedding,
it's about being careful in adding extra complexity or going in a
wrong direction.

There are other examples of changes that go through quickly and
without a lot of problem. Examples are the changes regarding 'issue
references' (issue_pat and friends), the refactoring of the VCS test
classes, and the recent update to V2 reCaptcha.

Regarding clean commits: it is an explicit part of the project
culture. From the docs/contributing.rst file:
    "We care about quality and review and keeping a clean repository history."

You have made clear in the past that you think this is often a waste
of time, but I disagree (and I'm pretty sure Mads does too). A clean
repository history is invaluable both during review, as during future
changes, to understand why something was done.
It would save time and frustration from all people involved if all
contributors take along this principle from the start when designing
and ordering commits. If you think from the start how your commit path
will be, the lost time is minimal. And when these commits are small
and well documented in the commit message, then review will be much
easier.
I'm glad that you split up the one big remaining bootstrap commit 'in
small parts', like we asked. Honestly, I think it was the only way
forward, and thanks to your cooperation we landed already a big part
of it.

>
> What troubles me the most about this, is the lag of communication. It
> sometimes takes weeks or even month to get any kind of feedback.
> I understand that people are busy, but as a leader of a project like this
> you should at least drop a quick sorry note and say when you will be able to
> look into the thing. Or delegate!

I agree that this is a weak point at the moment, and that we should
improve here.

>
> And I'm not the only one who has this problem. Our bitbucket is full of old
> PRs that went nowhere. Take the ssh PR for example. That one is 3.5 years
> old! I believe most of those people just gave up.

It's true that we need to pick up these old PRs or reject them. This
was agreed upon already a long time ago.
But the total bandwidth is limited, number of contributors is small,
so you can only do one thing at a time.
In the release 'roadmap' I proposed earlier [1] I suggested to finish
the bootstrap changes and then make a release 0.9, and shortly after
1.0.
At that point, I think we should try to reduce the open backlog. But
it makes no sense in trying to clean up the old backlog if the current
active PRs like bootstrap are not yet finished. It would only disperse
focus of all people involve, and slow down the bootstrap PR.

This is also the reason why I'm currently not actively looking at your
other PRs (like 'various changes' and 'hooks'): it would move away
focus from what we said is first priority. Just like you, I would like
to get over bootstrap as soon as possible so we can move on.

>
> I really believed this project had potential. But all my attempts to improve
> the communications or the projects organisation have been ignored. And my
> PRs were treated purely and very slow.
>
> What needs to change:
> - Stop pondering if some small change should be its own changeset
> This wastes A LOT of time. The quality of the code needs to have a higher
> priority then the quality of the changeset history!

Like I said above, I don't agree on this one. It's perfectly possible
to achieve qualitative code at the same time as a qualitative
changeset history. I would say it's the case for the commits currently
in Kallithea, and I have the same experience with other projects like
Buildroot.

> - Stop making the 'better', the enemy of the 'good'.
> If somebody comes up with a better solution in the future, great, but up
> until then settle with the good solution you have now.

In general I agree, partial progress is better than none.
But:
- the partial progress should be in the same direction as we want to
go in the long run, not a different one (so it means there may be
discussion to get agreement on what that direction should be),
- and when the 'distance' between the partial solution and the full
one is not too big, it makes sense to request the full solution at
once. Otherwise you end up with a codebase with only half-solutions
and nothing completely done.

> - Start using JIRA to manage and prioritize the open issues, PRs and other
> tasks.
> This projects simply needs to get organized.

I agree, have responded positively about this in the past, and we
'just need to do it'.
(not necessarily JIRA, like I said trac or something could be a good
alterative).

> - Promote riot.io as communication tool for more direct engagement.
> I mentioned before, that I think mailing lists and IRC are anachronistic
> tools. And they are not ideal to engage with people.
> In the mean time, Andrew set up the matrix.org bridge, which allows to use
> apps like riot.io to chat with our IRC channel. riot.io allows to always
> stay online and search in the conversation. But AFAIK practically nobody
> knows about it.
> Using the riot.io web and phone app can and will speed up the conversations
> a lot.

Like Long Vu, I'm unaware about this, I have not seen an announcement
on what and how.

While I dislike our IRC because the relevant people are not listening
at the same time, and there is no permanent presence,

I don't agree with mailing lists being a tool from the past. It is a
tool used in almost all FOSS projects I use, and that is because it is
something that works well.
You may perceive its asynchronicity as a bad thing and would prefer
more direct interaction, but that may be difficult with people having
different work and life schedules.

In fact, I would actually even argue to use the mailing list _more_
rather than _less_. Today, the list looks 'dead' because most activity
happens in PRs on either bitbucket or OOK. But these discussions are
not really 'public' in the sense that everyone can easily see them.
You have to explicitly search or follow these PRs to see any updates.
With such an approach, it's hard to build a community where different
people react to each other's changes. A mailing list PATCH sending
approach works better for that, or alternatively let OOK send updates
to the mailing list but this requires some changes like grouping the
comments (draft comment feature proposed at some point) and public
registration on OOK.

I would like to learn about and try riot/matrix before taking a stance about it.

> - Engage with people.
> It can not be that our PRs and open issues lay around for years. If there is
> no activity, a person in charge needs to reach out to the
> assignee/commiter/reporter. And if there is no hope that the issue/PR will
> be solved it needs to be closed. In general, talk to the people. There can
> be no silent treatment!

Generally I agree. But catching up with this takes time, and like I
wrote above it is also a matter of finishing ongoing things first.

> - Get serious about new features that make kallithea competitive.
> SSH, custom (git) hooks (activatable per repository) and scaleability are
> must haves. (kallithea currently does not work well with many user, many
> repositories or big git repositories)

I think we all agree that these are important points.
>From my point of view, the most constrained resource is time to write,
review and merge these changes.

I'm sure we'll get there. Any help from other community members is
more than welcome.
But let's first finish bootstrap, and then create some kind of roadmap
of what to tackle first.

/Thomas