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 _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9