Listing our current forces

[Steve Dodier-Lazaro]

Putting my ex-Xubuntu developer hat on.

It's fantastic when a project has the momentum to release things
often. It's less fantastic when a project ships buggy "innovations"
every release cycle. If you have a look at GNOME's past releases, they
introduced cool, innoative, sometimes frankly clever ideas every time.
But every time, they also introduced a lot of odd behaviours, tiny
bugs, inconsistencies between apps, etc. I just updated and again, I
had to file a bug report. And most of the times I don't bother because
I don't think my role as a user should be to ask that they finish
their implementations *before releasing* and not months/years after.

When I was working on Xub, I spent a lot of time dealing with the
crazy ideas Ubuntu was coming up with and making sure they didn't
break our users' experience, because our upstream just had their nose
on their list of goals for their project in their configuration and
the way they test it. They didn't even notice they broke things for
us.

My experience of fixed release cycles is very simple: people try to
look like they're progressing, they break shit, they ship horrendous
UX not because the new features are not cool but because users are
exposed to more interaction breakdowns because the edges aren't
polished.

I'm all in for *fast* release cycles, but not for fixed ones. I think
we can adopt an approach where we improve a component, compare what
we've done with what we used to have, polish the edges by
systematically using and exploring our new software, and then
releasing it. We're not there yet. For instance in the last wallpaper
UI redesign features were removed and if there was a rationale for it
it wasn't explained at all because on the user ML we had a user asking
why it's gone. We have the chance to have a diversity of skills here
and especially a lot of people who know how to design interactions and
test software, we should rely on those strengths and work as a team.
Running around trying to give the impression of speed might not be the
values our user bases expect of us, and it might not allow us to keep
the level of quality of Xfce as well as if we work together and
methodically.

So, if you agree with me, here is what I would like to propose:

1. We release components when they had critical bugs fixed, and when
they have been significantly improved.
2. The first step to improvement is identifying a couple of related
issues (such as the current lack of reliability of locker UIs, or the
lack of intuitiveness and relative invisibility of the session
resuming feature, or the Thunar crashes).
3. Then, a specification of good software behaviour or desired
features should be written. Looking at what others do and ensuring we
don't do the same mistakes as them is good at this stage. When a
specification can't be written out of the blue, call in the Design SIG
and let us do user research and provide recommendations.
4. Changes are implemented. Developers should really make sure to
identify all the little oddities at this stage, such as a change in
the UI of xfpm not being consistent with the UI of xfce4-session, etc.
5. Once changes are built, they should be tested. The testing teams
(aka Fedora, Xubuntu, Debian, BSD, Arch packagers and so on) test,
identify issues, report bugs. It is their responsibility if they ship
development versions and people find bugs and are unhappy, not ours.
6. Identified issues are fixed and changes are evaluated. Did we
remove features, or make them harder to use? If so, were they rarely
used or only for a niche of experienced users who can find them? Or
did they need frequent access or were relied upon by the newcomers?
(3-6 are iterative steps, so we shouldn't be shy about updated specs
as long as we freeze them at some point)
7. Release time! Freeze the features when we know we've done a step
forward, call on the translators, keep fixing bugs, and then release
an amazing and improved component.

I think the role of a release manager in such a scheme wouldn't be to
pressure competing team members to show something off, but to ensure
that people keep on track with the current spec and to identify where
progress is not made. For instance a release manager could say "we
need more developers to fix this list of open bugs, if you can write
code then stop whatever you're doing and help us out, please".

We have a wiki, we should make use of it to document all the packages
we want to see shipped in the future. Then they can be built component
by component and the components released as they progress. If people
are craving for version number changes we can bump the Xfce version
number every 2 or 3 or even every time we achieve something. We don't
have enough members yet to work on many things at the same time
efficiently so I think it's better if we all collaborate on one or two
small work packages at a time, and achieve steady progress.




2014-11-22 17:47 GMT+00:00 André Miranda <andreldm1989 at gmail.com>:
> On 11/22/2014 02:05 PM, Andrzej wrote:
>>
>> IMHO the key issue now is the lack a release manager. No releases = no
>> motivation to contribute to the project = stagnation. Since the most
>> active community these days is Xubuntu I would recommend giving (some
>> of) Xubuntu folks commit rights to all Xfce components and permission to
>> release stable Xfce versions every half a year. Assuming they agree, of
>> course.
>
> I can't agree more. Nowadays projects are wildly releasing (Firefox,
> Chromium, Systemd...), people (mistakenly) believe that a project that
> hasn't release a stable version in 1~2yr is dead (yeah, I'm talking about
> Xfce as a whole). While this is not true, this feeling of "not really moving
> forward" is unhealthy to the project, as people come to contribute, file
> some bug reports or upload a couple of patches and things end up in
> bugzilla. Eventually they give up and take for granted that Xfce is dead.
> Even if the patches are merged, few components are releasing as often as
> needed. Even tough if we have some components releasing regularly, Xfce
> itself is stuck in version 4.10 since 2012 April.
>
> In a nutshell, even if Xfce development is not as fast as it once was, I
> think we should try to release often, even if new versions feature only
> bugfixes. This alone is a message that the project is not dead and should
> encourage new collaborators.
>
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> https://mail.xfce.org/mailman/listinfo/xfce4-dev



-- 
Steve Dodier-Lazaro
PhD Student in Information Security
University College London
Free Software Developer
OpenPGP : 1B6B1670