-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonathan Lange wrote: > On Thu, Feb 11, 2010 at 5:02 PM, Aaron Bentley <[email protected]> wrote: >> 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? >> > > Very glad you agree. > > As for the case of something we don't know how to make excellent, I > don't know the answer. Do we need to have an answer now?
It depends how strongly you feel about refusing to do anything that isn't excellent. >> 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? >> > > I'd add "we must provide the user with an avenue for further enquiry > or a way of resolving the problem", and would challenge the second > requirement, because we could also show the user the error when they > next log on. Perhaps I'd counter by adding a constraint that we must notify the user *promptly*. But I am really working backward from an established solution. > Reflections / Thoughts:... Agreed. > So I guess I'm in favour of phrasing it strongly then trusting you to > break the rules when it makes sense I don't have a lot of respect for rules that I have to break in non-exceptional circumstances. >> 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. >> > > Damn straight. > > How can I help make this happen? A few ideas: - Convince the team leads that it is worth it to themselves as programmers and it will trickle down. - Point out success stories. - Convince people to give it a good, solid try, and analyse the outcomes with them afterward. If they feel it helped them, encourage them to tell others about it. > I guess one of the sources of tension in this discussion is simply > that I prefer mild hyperbole to precision in process documents, all > things being equal. Quite likely. I think that it's very hard to make rules that are clear to everyone all the time. I think hyperbole reduces clarity further. >> 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. >> > > What it's trying to get at is that paid work on new features or on > revamping existing ones is driven by business needs and user needs, > and that if you start something of that scale, you need to check that > it aligns with them. What scale? I can certainly contemplate features that take less than a day to implement. The conflict tracking recently added to merge proposals, for example. >>>> 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. >> > > I'm not sure that's correct. Often we talk of features and then do > nothing about them I was assuming a context where we have already decided to implement the change. > So I guess I'm not sure what the problem is here. Or, I do see the > problem, but it's a really deep one that already exists and that this > process simply makes explicit. The problem is that I will get blocked on you. This will stop me from doing work that I am supposed to be doing, and the document suggests that there is nothing I can do to fix this. I must wait until you, entirely of your own accord, you decide to address the work I am blocked on. > Even so, in the mean time we'd still need a place to list LEPs and > track their progress. I don't want the process to be blocked on that > and I dislike blueprints slightly less than I dislike editing tables > in moin. That may be, but the evidence suggests people would prefer to use other tools, and until there is a serious commitment to improve blueprints, I don't see the point of using them. > I'm saying that we should do some analysis up-front and some design > up-front. We already do this informally, I think, and should spend the > little extra time to write it down and share with others. Yes, but the idea of refusing to work on something that isn't excellent means that we must design a feature thoroughly before we are ready to code. That, to me, is big design up front. So providing a new set of procedures for doing design up front while simultaneously saying you wanted to avoid BDUF seemed contradictory to me. > On a meta-note, this discussion has been very useful to me in > clarifying my thoughts and improving the docs, but gosh it's a big > discussion. I've spent a fair bit of time on my replies, and would be > happiest if the discussion (or even our opinions!) converged rapidly > after this one. I can understand that, and I think we've made a lot of progress, but I also think that changing our development methodology is a serious matter, and it's worth spending a bit of time on. Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkt1aYQACgkQ0F+nu1YWqI3GyACfR26epZDi5pmbnV3nO6KPszIL iM4AnR1TBXGBUmh6L5d5Lg4GDeRUZW2q =WINC -----END PGP SIGNATURE----- _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
