[Bf-funboard] UI talk + session at bconf

Brecht Van Lommel brechtvanlommel at pandora.be
Thu Sep 26 02:30:56 CEST 2013


On Wed, Sep 25, 2013 at 10:44 PM, david j <davidj at gmail.com> wrote:
> 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.

Ok, what I understand by setting up a UI module team is not something
has already been done. It's both finding manpower who want to take
responsibility, and setting up a (formal or informal) process.

On Wed, Sep 25, 2013 at 10:44 PM, david j <davidj at gmail.com> wrote:
> (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.

Agreed.

(But let's not use GSOC as an example that fixes this, it's very time
consuming for core developers in practice)

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

For UI patches yes, UI design and decision making is a big part of the
issue. I would like to stress though that it's not just accepting or
rejecting patches, but getting feedback from experienced users,
thinking about alternatives, or realising that it's actually a bigger
issue that the patch provides a poor solution to.

> 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!

Ok, that's a good suggestion. I do think in practice the separation
between UI review and code review isn't so easy to make. The developer
does need to understand the patch deeply, assuming the external
developer did is not a good assumption in my experience :)

But if the design has already been improved and there's a general
agreement from the UI designers, then that would make things go a lot
smoother, I'd be happy if I could do reviews mostly at the code level.

Anyway, I guess everyone can agree we need to set up some sort of UI
module team and process. I hope that can happen soon-ish but I can't
make many decisions while Ton is on vacation.

Brecht.


More information about the Bf-funboard mailing list