[Bf-funboard] UI talk + session at bconf

david j davidj at gmail.com
Wed Sep 25 22:44:29 CEST 2013


>
> I don't understand how what you are saying is different. My point was
> that lack of user feedback isn't the problem, but rather that
> developers are occupied with work on other areas and that there is no
> UI module team to make decisions. I'm talking here about a lack of

people that have ownership and responsibility over the code. So as a
> result, patches are not getting reviewed, decisions are not made, etc.
>

Sorry, I didn't explain myself very well.

I agree with many things you're saying, and I like the questions in your
document. I agree there is no lack of user-feedback, and that
committers/code-review is a bottleneck. I agree many suggestions don't
consider all the factors, and I agree that feedback noise sometimes makes
it hard to notice the coherent proposals.

However, based on what I've seen, I believe there is more of a process
challenge than a manpower challenge.

As a result, I don't think strictly adding more committers or identifying
module teams (which has sort-of been done) will improve the situation
greatly without also making process changes. Fortunatly, I think process
improvement will dramatically change things. You can see this a bit in the
success of GSOC projects, because they have a better process with more
up-front buy-in and approval. However, let me explain in more detail why I
say this.

(1) Code review should not be UI review. It's a frustrating and chaotic
time waste to have UI decision discussions through code patches. Also,
non-committer developers should not be wasting their time with code that
hasn't been UI "approved" by somebody. (at least in the sense that it "is
an interesting direction to explore") In a way, the GSOC process fixes
this, because there is an approval step and mentor to a GSOC project.
However, smaller contributions don't really fit into this heavy weight
model very well.

(2) From my admittedly limited experience, I think code-reviews shoulder
too much burden. Open source is not about committers understanding every
line and potentially rewriting the patch him/herself. It's about leveraging
a community of developers efficiently. For sure not all patches are awesome
code, but to have the reigns in this tight essentially makes the committers
re-do all the work, even if someone else did the work first. I think this
partially happens because of the old (broken) release process, where bugs
too easily made it into official releases, because a typical longer
alpha/beta/RC process was missing. The recent release process changes
should help with this. I think the other cause is #1 above, where
committers are not sure whether a UI change made by a patch is actually
accepted. Here a committer inappropriately shoulders the burden of being
the UI designers as well.

Fortunately, I think these two issues are relatively easy to fix with
process changes. I propose the following:

(1) Creating an explicit UI-change proposal and approval process where
(coherent) UI proposals can be discussed, and get an "approved" "needs
improvement" or "not likely now" or "not likely ever" disposition. I
propose doing this with a new tracker category, but making a more
'formalized' process around the wiki TODO list would be okay also. Even if
Ton is the only one making the final decisions, and he only dedicates a
little time to it, IMO it would still be better than the current process.
(a) because developers could stop wasting time on ui-change patches which
are not approved, focusing on the ones which are approved, and (b) When a
patch with UI change is submitted, it could just reference the "approved"
UI-change tracker item, freeing the code-reviewer from having to serve as
the UI gatekeeper. A broad set of "goals and priorities" could be a
catch-all for small changes (like making sure everything has tooltips). --
For sure a UI-change submission process like this would have some "noise".
I personally volunteer to help pre-review submissions and help them either
clarify them enough to be coherent, de-dup them, or explain why their
request may be user-ignorance.

(2) With the new release process, and a UI-change process like the above,
the reins should be loosened on the patch-commit and code-review process.
Assuming a patch does something approved, the code follows coding
standards, and the patch appears to do what it says it does, the process
should be little more than a short feedback/question cycle and commit. Not
a burden for the committer to deeply understand patch in the same way the
external developer did. That is presumably what the developer did when he
made it! This is how open-source gets velocity, by cheaply leveraging the
developer community to fix and improve things!

Did you see the difference in perspective there?


More information about the Bf-funboard mailing list