From 12bdf43ab2d2f23413a625a843a1cafea25c0386 Mon Sep 17 00:00:00 2001 From: Edward Powell Date: Sat, 30 Mar 2013 00:25:05 -0400 Subject: [PATCH] [docs] Add NEWS and CONTRIBUTING files --- CONTRIBUTING | 44 ++++++++++++++++++++++++++++++++++++++++++++ NEWS | 11 +++++++++++ 2 files changed, 55 insertions(+) create mode 100644 CONTRIBUTING create mode 100644 NEWS diff --git a/CONTRIBUTING b/CONTRIBUTING new file mode 100644 index 0000000000..b266b5d8db --- /dev/null +++ b/CONTRIBUTING @@ -0,0 +1,44 @@ +How to contribute +================= + +The Willie project welcomes patches from third parties. There are always things +that can be improved, and we can't always do all of them ourselves. We love it +when people help out. + + +Submit Issues +------------- +It's very important to us that we know when our code is failing. As such, we +greatly appreciate when users submit tickets on the GitHub issue tracker. Be +sure to describe your issue clearly and concisely. It's also a good idea to +include the version you're running, your operating system, how you installed +Willie (via your package manager, pip, setup.py install, or running straight +from source) and, if applicable, the relevant output from the log files in +~/.willie/logs. + + +Commit Code +----------- +We prefer code to be submitted through GitHub pull requests. We do require that +code submitted to the project be licensed under the Eiffel Forum License v2, +the text of which was distributed with the source code. + +In order to make it easier for us to review and merge your code, it's important +to write good commits, and good commit messages. Below are some things you +should do when you want to submit code. These aren't hard and fast rules; we +may still consider code that doesn't meet all of them. But doing the stuff +below will make our lives easier, and by extension make us more likely to +include your changes. + +* Commits should focus on one thing at a time. Do include whatever you need to + make your change work, but avoid putting unrelated changes in the same commit. + Preferably, one change in functionality should be in exactly one commit. +* pep8ify your code before you commit. We don't worry about line length much + (though it's good if you do keep lines short), but you should try to follow + the rest of the rules. +* Test your code before you commit. We don't have a formal testing plan in + place, but you should make sure your code works as promised before you commit. +* Make your commit messages clear and explicative. Our convention is to place + the name of the thing you're changing in [brackets] at the beginning of the + message: the module name for modules, [docs] for documentation files, + [coretasks] for coretasks.py, [db] for the database feature, and so on. diff --git a/NEWS b/NEWS new file mode 100644 index 0000000000..4cd0befb04 --- /dev/null +++ b/NEWS @@ -0,0 +1,11 @@ +Changes between 3.1.2 and 3.2.0 +=============================== +* tools.Nick class added for RFC-compliant nickname comparison and storage +* Returning willie.NO_LIMIT from a callable ignores the rate limit for that call +* get_list() added to ConfigSection. Will reliably return a list from a config attribute. +* A number of bugs regarding admin and operator lists were fixed +* Unusual mode changes no longer cause errors +* Times shown by .t, .in, etc. all now use formats set by .settimeformat +* sed feature can use backslashed slashes in substitutions +* Weather module was rewritten, and now uses Yahoo! Weather +* Numerous stability and usability fixes