launchpad-dev team mailing list archive

[Aaron Bentley <aaron@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jonathan Lange wrote:
> On Wed, Feb 10, 2010 at 11:49 PM, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:

> As Martin put it, I meant this as a toolbox from which people can use
> what fits the situation, not as a straight jacket, nor as a set of
> hoops to jump through.

You said "I'm proposing that before we begin work on _anything at all_,
we run through this checklist: bugs, refactoring, features, whatever".
You used emphatic language and underscores, so I took you literally.

Because I thought "positively" in ReadyToCode meant "affirmatively", I
thought that all questions had to be answered "yes".  That would be a
set of hoops to jump through.

Put those together, and you have a straitjacket.  If you didn't actually
mean "anything at all", nor that all questions had to be answered
affirmatively, I'm happy.

> Some of your specific points have made me think more broadly. I've put
> those broader thoughts in with the answers to the specific questions.
> 
>> Jonathan Lange wrote:
>>> Ultimately, it's not going to happen unless we all refuse to make
>>> anything short of excellent.
>> Are you sure that this is true?  Can't we start by making something
>> useful, then make it good, then make it excellent?  Can we be sure that
>> something is excellent before we even start coding on it?
>>
> 
> Of course we can start by making something useful, then good, then
> excellent. I hope I never implied otherwise.

I got that implication from "it's not going to happen unless we all
refuse to make anything short of excellent."  Refusing to make anything
short of excellent would mean refusing to make anything merely useful or
good.

> What I'm saying is that we shouldn't _stop_ working on something until
> it's really very good. I could point to specific examples of where we
> have done this.

I'm fully behind that sentiment, and I agree we've had problems like
that.  What if we find cases where it's good and we don't know how to
make it excellent?

>>> 1. https://dev.launchpad.net/ReadyToCode
>>>
>>> It's a very short list.
>> Couldn't it also be seen as long?  It is actually eleven points, and
>> many of them look like they would take more than a few minutes to complete.

I would still like to see a response to this.

>>> If you can answer every question on this list clearly, convincingly and positively, then you are ready to code.
>> By "positively", do you mean affirmatively, not "with good spirits"?
>>
> 
> I think I meant a bit of both. I meant to guard against people
> answering "Yes" or "No" without qualifying it. Perhaps a better word
> would be "specific".

Hmm, that's very different from the meaning I took.  I took it to mean
"affirmatively", which would mean that "yes" answers would be required
for every item on the list.  I think "convincingly" already covers most
of what you mean, possibly something about justification would help.

> How can I make it clearer on the wiki page itself?

Maybe something like "A rationale should be provided if the answer is
no"?  And I think "positively" is too ambiguous to stand alone, so it
should either be explained or removed.

>> Why does it make sense to generate a list of representative users /
>> stakeholders for a trivial bugfix?  Why does it make sense to talk to
>> them?  Do you mean vocal communication, or if not, which forms of
>> communication do you mean?
>>
> 
> I would argue that the representative user for a trivial bug fix is
> the person who filed the bug. I would argue further that it's good to
> ask something of that person when you fix it. e.g. "I've fixed the
> bug, can you give it a try?"

It might be a good idea, but this process happens before you fix the
bug, so I don't see how it's relevant.  Could you take another stab at
answering this?  Especially the bit about forms of communication?

>>> What are the constraints on possible solutions?
>> Why should we consider this for a trivial bugfix?  Isn't this likely to
>> degenerate into justifying the obvious solution after the fact?
>>
> 
> To be honest, I've never tried, though I'd like to.

So, here's one that's fresh in my mind: bug #492275.

The fix is:
@@ -581,8 +582,13 @@
                 [message.get('from')],
                 'Error Creating Merge Proposal', body)
             return
- -
- -
+        except BranchCreationException, e:
+            body = get_error_message(
+                    'branch-creation-exception.txt', reason=e)
+            simple_sendmail('merge@xxxxxxxxxxxxxxxxxx',
+                [message.get('from')],
+                'Error Creating Merge Proposal', body)
+            return
         try:
             bmp = source.addLandingTarget(submitter, target,
                                           needs_review=True)

Now, to me it seems obvious that we should handle this kind of error the
way we handle other kinds of errors in the same situation.  I don't
think that it makes much sense to revisit the constraints.  If pressed,
I'd say the constraints are:

- - we must explain why their merge proposal was not created
- - we cannot do this using a web page, because the user will not
necessarily be using our web site when this error is encountered

Do you have any insight?

> If it's make-work, don't do it.
> 
> More broadly, there are two ways you can think about trivial bug fixes
> and this RtC list.
>   1. ReadyToCode doesn't apply to trivial bugfixes
>   2. A change is trivial if most of the ReadyToCode list doesn't apply.
> 
> I'm thinking the second way and it sounds like you are inclined to the
> first way. I don't think it matters much which way you approach it,
> just as long as the list is used as a bunch of prompts to genuine
> thought.

Your initial email doesn't admit the possibility of 1; you said "I'm
proposing that before we begin work on _anything at all_, we run through
this checklist: bugs, refactoring, features, whatever".  You used
emphatic language and underscores, so I took you literally.

Because I thought "positively" meant "affirmatively", I didn't think
that 2 was an option either.

>>> Have you talked to someone else about this?
>> If I have talked to representative users / stakeholders about this, then
>> I have spoken with someone else about this.  Isn't this redundant?
>>
> 
> In my head, I was thinking of two things:
>  - another Launchpad hacker
>  - it's really quite important to speak to someone else, so maybe put
> it in twice

I think specifying "another launchpad hacker" would make more sense.
Maybe even "an experienced launchpad hacker"?

>>> Do you have a list of the UI workflows for the feature?
>> How does this apply to a trivial bugfix?
>>
> 
> "There are no changed workflows"

Cool.  (Not affirmative, so I didn't think it was an option.  [Unless "I
have a list.  It is the empty list," is affirmative])

>>> I'm proposing that before we begin work on
>>> _anything at all_, we run through this checklist: bugs, refactoring,
>>> features, whatever.
>> Why is this appropriate for bugs and refactorings?
>>
> 
> It's appropriate to think about why you are doing something,
> regardless of whether it's a feature or a refactoring. I also think
> there are some good things that should be done often (like UI mockups
> & pre-implementation calls) and that it's worth making an explicit
> decision *not* to use them, rather than forgetting to use them.

I think that this requires changes to our programming culture, and while
checklists and policies can contribute to that change, they cannot stand
alone.  People need to believe that these things are worthwhile to them,
or at best they will do them grudgingly.

>>> It might be a useful thing to use for
>>> pre-implementation calls.
>>>
>>> 2. https://dev.launchpad.net/LaunchpadEnhancementProposalProcess
>>>
>>> If getting ready to code is actually non-trivial, then you might want
>>> to use this to help get there. I've tried hard to keep it as simple as
>>> possible.
>> The "do not need to follow" list seems to overlap with the "definitely
>> need to follow" list.  For example, I could be adding a new feature, yet
>> have clear, convincing and positive answers to the checklist.  How
>> should I resolve this apparent contradiction?
>>
> 
> Good question. I don't really know how to change those lists (which
> are meant to help you decide instead of actually deciding for you),

I recommend changing their descriptions, then:
"You do not need to follow this process if" => "Factors suggesting you
do not need to follow this process"

"You definitely need to follow this process if" => "Factors suggesting
you should follow this process"

>>> The Product Strategist triggers this process and approves any output from it.
>> Why can only the Product Strategist trigger this process?  Combined with
>> the "you definitely need to follow this process" list, this seems to
>> imply that the product strategist will decide which features to
>> implement and rework, which workflows to extend or change.
>>
> 
> It's my understanding that it's actually my responsibility to do so.
> Francis can correct me if I'm wrong.

Do you think that this makes sense for a small feature or minor
reworking of a feature?

> I should have communicated more about the role earlier and better.
> These processes are part of an attempt to be more explicit, and also
> to figure out the details.

That doesn't seem to explain why only you can trigger the process.  As
written, the documents state that a developer can determine that they
need to follow the LEPP, but they cannot actually start the process.  It
seems strange.

>> How can it be reconciled with "have spent more than thirty minutes
>> talking..."?  The only way I can reconcile it is "If you spend more than
>> thirty minutes talking about a change, you must abandon it, until such
>> time as the Product Strategist decides that should should implement it."
>>
> 
> Well, what were you going to do with it?

Sorry, I don't understand the question.  Normally, I would continue to
implement the feature.

>>> In the process, I suggest that we use blueprints for keeping track of
>>> these proposals. I think it's time we started eating our own dogfood
>>> again.[2]
>> Do you agree that the purpose of eating our own dogfood is so that we
>> can improve it?  If the dogfood has already proven unpalatable and there
>> has been no concerted effort to improve its flavour, shouldn't we
>> improve the dogfood before attempting to eat it again?
>>
> 
> Maybe. Can you suggest a tastier alternative?

Let's to a LEPP called "make blueprints awesome in a month".  When we're
ready to code, we steal one team member from each team to make a virtual
blueprints team, implement the LEPP, and start dogfooding.  But we
should only dogfood if some people are given responsibility and
opportunity to implement improvements.  Otherwise, it's just an exercise
in futility and frustration.

>> Speaking of dogfood, have you considered applying these proposals to
>> themselves

> I hadn't, and not all of them apply because it's not code, but here goes:

This pretty useful, so that validates the checklist to me.


>>> Create the blueprint
>>> Create the wiki page
>>> Talk to someone
>>> Start adding constraints
>>> Jot down sub-features
>>> Identify workflows
>>> Get it reviewed
>> It seems plausible that all these activities would take longer than the
>> time it takes to implement the feature, reducing the time available to
>> do iterative improvement.  Is that an acceptable tradeoff?  If so, why?
>>

What do you think?  Am I wrong about the time this will take?  If I'm
not, is it an acceptable tradeoff?

>> Are you sure that this is not big design up front?  What makes it different?

> Because analysis and design are two different things. Being clear on
> the problem is not at all the same as making decisions about the
> solution.
> 
> The UI mockup work is in there mostly because we're already required
> to do it, it helps and having two separate things for it seemed
> mechanically clunky (although conceptually cleaner).

Analysis and design may be different, but from what I can tell, this
process does both.  LEPP does insist that design be informed by
analysis, and that's a good thing.  I still think it's all being done up
front, though.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkt0OAcACgkQ0F+nu1YWqI1iSQCeOYZbZC6HYfuclVweFMOnhPlI
b68An3RVgIhIKp1/eMGnE9RXpKnGYTLm
=d+c7
-----END PGP SIGNATURE-----