Improving our review criteria

[Maritza Mendez]

Once again I am impressed with the openness of the bzr community.
This is a dialog I have participated (and facilitated) many times but
always behind closed doors.  This is good for bzr.

So as a bzr user greedy for new features to support adoption let me
make two points that may surprise some of you.

1. I differentiate between missing features and broken features.
Missing is ok.  Broken is not ok.

2. The first thing I looked at when evaluating bzr was the user
documentation. The second thing...and this is what closed the
deal...was the test suite.  No I am not an expert in bzrlib or even
python.  But I recognize quality in any language.  Bzr has quality.
And that is really important in a vcs tool.

So please count mine as one voice in favor of maintaining a policy of
test coverage for new features and internal code quality control to
avoid creating traps for future maintenance and development.
Shortcuts are never cheap.  Pay now or pay later.

The present balance feels about right to me.  And initiatives like
Vincent's shell like tests greatly ease the testing burden on newbies
like me who are probably more focused on UI issues than architecture.

Thanks for reading.  I know this note is long.  Quality perception is
very important to the future of bzr (more than politics for example)
and I am confident that whatever course you choose, you will monitor
the consequences closely and make adjustments as needed.  Again I'm
impressed with your openness.

~M





On 11/12/09, Ian Clatworthy <ian.clatworthy at canonical.com> wrote:
> The Bazaar core team has always had a very strong emphasis on quality
> and that's a great thing. My big complaint though is that our review
> criteria favours "developer quality" over "user quality". In particular,
> patches land if:
>
> 1. They improve the product.
> 2. They don't reduce test coverage.
> 3. They don't reduce internal clarity.
>
> I think the last two things should be taken into account but not be
> blockers to landing as they are now. Why?
>
>  From my perspective, "quality" is how well a product meets user needs.
> Great software teams follow the Agile philosophy of ...
>
>    maximise the rate at which you deliver *value to the customer*
>
> If a change makes life better for thousands of users, we're actually
> *improving* quality of the product vs not landing it, even if that
> change has less tests that it should or it could be implemented using
> "cleaner" layering. We certainly need to closely monitor technical debt,
>   use refactoring, etc. but, right now, I think our review criteria is
> skewed in favour of 10-20 core developers instead of our user base (80k
> at a rough guess) or our potential user base (several million).
>
> It's actually ok to release software with bugs. To give a concrete
> example, Bazaar Explorer gained virtual repositories in 0.9 even though
> they only work locally and not remotely. I knew that before I released
> it but I felt it was ok because 99% of users wanting that feature are
> browsing local disks. Delaying the feature to fix all the issues would
> have reduced quality IMO.
>
> We certainly should focus on overall solution quality but test coverage
> is only one dimension of that. If we're missing features and that's
> stopping projects from considering Bazaar or migrating to Bazaar, we
> aren't meeting user needs regardless of the warm fuzzy feeling we get
> from our fantastic test suite. It's also important to keep in mind that
> there are multiple ways of achieving great quality. These include:
>
> * gaining more users - all bugs are shallow given enough eyeballs
> * rapidly turning around "easy" bugs as users submit them.
>
> In summary, I think our emphasis on quality is awesome but I'd like to
> see us put the user more at the center of it. Stuff like better
> packaging, easier migration, cleaner documentation and faster feature
> rollout need higher emphasis in our culture IMO.
>
> Ian C.
>
>