It seems like if you are doing a significant change to an existing area or adding a feature, it is good to explain the change that you're planning to do (and hopefully get input from whoever had been working on that area recently the most). This explanation doesn't have to be a "design doc" though.
For example from bug https://bugs.webkit.org/show_bug.cgi?id=25463, "The comments in the bug seem to show a lack of consensus as to whether we want this feature and whether the API is appropriate. *These design issues should be** **hashed out (perhaps on the mailing list) before submitting a patch for code review.*" Dave On Mon, Jun 29, 2009 at 10:22 AM, Eric Seidel <[email protected]> wrote: > > It seems to be a common misconception of Google engineers joining > WebKit that WebKit expects design docs like Google does. > > I see Google writing design docs a lot. I saw one or two in my 3 > years at Apple. I've never seen WebKit use them. > > Google engineers posted 3 design docs to webkit-dev last week. I > doubt any of those docs will get much feedback, but I could be wrong. > > > And then this response today: > > On 2009-06-29, at 02:05, Johnny Ding wrote: > > > It will be better to send out detail explanation/design doc before > sending patches if the changes are big:) > > Since when has writing a design document been part of the process of > contributing to WebKit? > > - Mark [Rowe] > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
