[Mailman-Developers] Getting "approval" to go ahead

[Barry Warsaw]

On Mar 24, 2015, at 02:38 PM, Andrew Stuart wrote:

>I haven’t really worked on an open source project before.

You're fitting right in though! :)

>It wouldn’t make sense to come up with an idea, write some code, submit it
>and have it rejected because it’s not OK with the project owners and doesn’t
>fit with project goals.

I think Terri summarized things well, so I'll just add a few things as it
relates to core.

A Launchpad bug is always a good place to augment a mailing list discussion.
You can hang branches and merge proposals off of bugs, and we can have a
conversation about the details of either the idea (on the bug) or the
implementation (on the merge proposal).

Always tag the bug 'mailman3' for Mailman 3.  It helps me find them better.  I
can then triage the bug, assign it to a milestone, raise or lower the
priority, etc.

Let's say you have a crazy idea for a new feature.  Bring it up here and let's
start the discussion going.  If it seems like a good idea, and aligned with
the project goals, create a bug and start hacking.  Attach your branch to the
bug.  When you think it's ready for review, create a merge proposal against
trunk (i.e. lp:mailman).

Some things that I look for right away: conformance to PEP 8 and our own style
guide.  I don't expect branches to be 100% conformant to style, but I think
it's not hard to get close if you follow the guides and try to look like
existing code.

Doctests that explain the feature and unit tests that cover the new code.
Doctests are documentation first, so are expected to explain good-path
behavior and usage.  Unit tests cover corner cases, error conditions, etc.
Tests should be included at each appropriate level (e.g. model, REST).  The
tests should fail without your "fix" and pass with them applied.  There should
be no regressions in the rest of the test suite.

Keep feature and bug branches small if possible, and concise, such that they
only implement the feature your working on or fix the reported bug.  A little
bit of extraneous stuff might be okay if it improves readability, but don't go
overboard.

That's probably the basics.  I promise I will try to be kind, fair, and
thankful for your contributions, though I might be rather strict in my
opinions.  If you really disagree, let's discuss respectfully!

Cheers,
-Barry