Thanks very much for this, Stamatis. It is really helpful and +1 to
add them to website.



Best,
Chunwei


Best,
Chunwei

On Thu, Apr 25, 2019 at 10:43 PM Julian Hyde <[email protected]> wrote:
>
> Thanks for this, Stamatis. Much needed.
>
> I agree with Vladimir that this should end up on the site, but it is 
> appropriate that it starts as an email discussion, so that we can build 
> consensus.
>
> A few more things.
>
> The subject line of a jira case (and a commit) is important.  Crafting it is 
> an art. It should imply what the end user was trying to do, in which 
> component, and what symptoms were seen. If it’s not clear what the desired 
> behavior is, rephrase: eg “Validator closes model file” to “Validator should 
> not close model file”. Contributors to the case should feel free to rephrase 
> and clarify the subject line. If you remove information while clarifying, put 
> it in the description of the case.
>
> Design discussions may happen in varying places (email threads, github 
> reviews) but the case is the canonical place for those discussions. Link to 
> them or summarize them in the case.
>
> When implementing a case, especially a new feature, make sure that the case 
> includes a functional specification of the change. E.g. “Add a IF NOT EXISTS 
> clause to the CREATE TABLE command; the command is a no-op if the table 
> already exists.” Update the description if the specification changes during 
> design discussions or implementation.
>
> When implementing a feature or fixing a bug, endeavor to create the jira case 
> before you start work on the code. This gives others the opportunity to shape 
> the feature before you have gone too far down (what the reviewer considers to 
> be) the wrong path.
>
> Julian
>
> > On Apr 25, 2019, at 6:51 AM, Vladimir Sitnikov 
> > <[email protected]> wrote:
> >
> > Stamatis> If you see things that are
> > Stamatis> incorrect or that need to be done differently feel free to
> > reply to this
> > Stamatis> email.
> >
> > LGTM.
> >
> > Stamatis, thanks for the writeup, however I'm inclined to suppose it
> > makes sense to put that on the website.
> >
> > Such mails will be hard to find, especially for the ones who don't
> > know such a mail exists at all.
> > On the other hand, "/develop/" page is trivial to navigate even by
> > just browsing the website.
> >
> > Vladimir

Reply via email to