[Bf-funboard] UI talk + session at bconf

david j davidj at gmail.com
Tue Oct 1 01:23:16 CEST 2013


On Mon, Sep 30, 2013 at 11:42 AM, Jason van Gumster <
jason at handturkeystudios.com> wrote:

> > What is subjective about the changes? I see nothing subjective. I removed
> > the subjective behavior change by making a new patch.
>
> What's subjective is the opinion that the current naming/behavior is
> misleading or confusing. That should be clear enough from the fact that
> you got rational user pushback from this series of patches.
>

Not only were those changes removed, I explained they were removed in the
text *you quoted* in your email. So I don't understand your response at
all.

In addition, I did not bring up this patch to get buried in details about
the patch. (** see below if you care) I brought it up as an example of
opportunity for process improvement. This is the third reply getting buried
in factually incorrect discussion about the example and which has ignored
the process discussion.

(1) I'd personally like to know how I can get a subjective UI change
proposal clearly approved or denied.

So far these mailing lists have not been very useful for this purpose. To
paraphrase a BF committer, they just feel like shouting into the wind, and
I agree with this characterization.

Any UI change proposal is subjective, and may receive both push-back and
interest. However, neither of these are a decision. As far as I can see,
the current UI decision process is "if you commit it, it's a UI decision
unless someone reverts it", which is not something non-committers can be a
part of.

In order for a group to make progress on anything, it is important to have
a decision making process. This is why companies are structured as
hierarchies.. to make decisions and resolve deadlocks.

The recommendation I made earlier is to create a separate tracker section
for UI proposals, with some structured requirements. I'm curious what other
people think of this idea, and if they have other ideas how one might get a
clear decision about a subjective UI change proposal.

(2) To me, this whole committer/code-review process seems overly
bureaucratic. So far the amount of time I've spent politicking to get
bugfix patches committed outweighs the time to create them by a factor of
10x. More if you count the time spent by others listening to the
politicking. It feels like Trantor level muck and mire, and BF is not that
big an organization.

Campbell mentioned on IRC that some of this has to do with the lack of
tests, and the resulting care with which any patch is accepted. However,
IMO this needle is swung too far in the wrong direction. I think the
code-review process should have TIGHTER controls about behavior changes
(aka, all behavior changes must have an approved tracker item using the
above new process), but LOOSER controls about whether a committer fully
understands everything about the patch (which can take as long as writing
the patch to begin with).

Right now the development process feels more like corporate shared-source,
where external developers can look at the code, but they can't actually
help fix it. At least not without spending countless hours re-educating
people who don't even understand what it was they fixed.


** regarding my spline patch - I talked to Campbell, and it seems the real
problem getting my 2nd patch in is that there is no current maintainer for
this code. Which means even if the patch is perfect, it's really hard for
anyone to code-review it. We decided on a plan of action where I'll file a
bug for each specific bug I fixed, and separate a couple bugfixes into
their own micro-patches. It feels a little granular to submit 4 3-line
patches, but if it's easier that way, so be it.


More information about the Bf-funboard mailing list