Re: GNOME Shell Modal Dialog Tweakage

[Allan Day <allanpday gmail com>]

On Sun, Mar 11, 2012 at 1:02 AM, Shaun McCance <shaunm gnome org> wrote:
> Replying to two in one, to save electrons.
>
> On Sat, 2012-03-10 at 13:03 -0500, Matthias Clasen wrote:
>> On Sat, Mar 10, 2012 at 9:49 AM, Allan Day <allanpday gmail com> wrote:
>> >>
>> >> Now, if we want to define and write down an exact list of things we do
>> >> not require approval for (but still require notification), I'm OK with
>> >> that.
>> >
>> > I don't recall suggesting that you construct "an exact list of things
>> > we do not require approval for". All I'm saying is that a single
>> > sentence isn't a lot to go on. A few more details would be helpful.
>
> Allan:
>
> What I'm saying is that all the extra verbiage is what we would need
> to have exceptions. The single sentence right now is very clear. It
> doesn't mention exceptions, therefore there's no reason to assume any.
>
>> > It's clear that many people don't understand the rules the way you do.
>
> And that's why I engage developers when I think they're not following
> the release process. I'm happy to have a more public discussion about
> this. Our release process is always evolving, and I've always taken
> part in those discussions.
>
>> I think it is important to not lose sight of the goal here.
>>
>> The freeze is not there so we in the release team or the documentation
>> guys can feel empowered.  The goal is to ensure that we end up with a
>> high-quality release and docs that match the actual product well
>> enough to not confuse users.
>
> Matthias:
>
> I think one of the big benefits of the freezes is that they act as
> a deterrent to making lots of small changes.
>
> One small discrepancy isn't a big deal. As you mentioned earlier,
> very few people will likely even notice a discrepancy in the docs
> with this particular change. (By the same token, though, very few
> people will notice the change at all, and that makes it much less
> urgent to get it into this release.)

I wouldn't have pushed this change if I didn't think it was urgent. As
you say below, details matter.

> But if we don't discourage changes after the freezes, then it won't
> be one small discrepancy. It will be 20 or 50 or 100. And then our
> help and marketing materials and other stuff look unprofessional.
> Yes, I care if our help looks professional. I care that it gives
> the impression that it's current, because we're fighting a user
> perception problem born out of a decade of useless and outdated
> manuals. Details matter.
>
> Allan only sent a notification because another developer suggested
> he should. And he apparently made some font size changes without
> notification. That suggests to me that people are not deterred at
> all from making post-freeze changes, and that potentially lots of
> small changes are being made that I don't know about. It adds up.

Well yes, one patch changed some text from 10.5pt to 11pt. I think
there was another one that changed a text style from 9pt to 9pt bold
(all part of a much larger theme cleanup, I might add). These are
exactly the kinds of changes that shouldn't require freeze breaks, in
my opinion.

> That suggests to me that people are not deterred at
> all from making post-freeze changes, and that potentially lots of
> small changes are being made that I don't know about. It adds up.

Personally speaking, there are two issues here.

The first is the apparent lack of consensus. I was following what I
understood to be good practice, and even went out if my way to be
considerate towards the docs team. It's frustrating to then be told
that I'm breaking the rules. I largely agree with Matthias's last
message, but I also want some clarity.

The second issue is what the policy should actually be. This is really
up to the release and docs teams, but my personal opinion is that
minor cosmetic changes that don't impact on the docs shouldn't require
a break request. We're busy enough without having to jump through
extraneous bureaucratic hoops.

Allan