PyData NYC Sprint 2018 April 11
Thank you for participating in this dateutil sprint event. In addition to the issues on the issue tracker (which have been organized by labels), other general improvements - particularly to the documentation, build and test - would be very useful.
Two talks that might be useful, particularly for those who want to improve the documentation:
- PyGotham 2016 - Overview of dateutil library (~30m): Video, Slides
- PyBay 2017 - Deeper dive into time zones and how they work (~40m): Video, Slides
- Event code for wifi is "msevent05ap"
- Rooms booked: Ambassador (6202) and Belasco (6203)
- help wanted - Issues that have been vetted and where a PR (or other solution) would be welcome.
- good first issue - These are issues that would probably be good for a first-time open source contributor.
- low difficulty - These are issues where the implementation should be fairly straightforward.
- medium difficulty - These are issues where the implementation is somewhat complex (though almost all of them can likely be accomplished in less than a day for intermediate to advanced Python users)
- tests - Pertaining to the testing
- build - Related to CI build and release
- documentation - Documentation improvements
- time zones - tzinfo classes (tz documentation)
- recurrence rules - rrule documentation - based on RFC 5545 (obsoletes RFC 2445)
- parser - Parses datetime strings (parser documentation)
- relativedelta - Calendar and other "relative" offsets (relativedelta documentation)
These are some important issues that I would very much like in the next release. They are all medium or medium-high difficulty.
- Adding no-zoneinfo build options. This is basically already done and needs some additional testing. This is a medium-high difficulty item.
-
Implementation of the
skipoption in rrule. This is very important and very nearly done.
- tzwin module not building on readthedocs. This module has documentation but none of it is present on the website because of this bug!
-
Start testing against master on the
tzlibrary. In particular we should be building the "vanguard" version of the tz database. - Start testing against pypy on Windows - again, medium high difficulty.
We also welcome other general improvements for which there is no specific issue. The biggest "unstructured" improvements to be made are around test coverage and documentation.
The easiest thing to do to improve the testing is getting coverage to 100% (#521). This can be done by navigating through the codecov coverage report and finding lines untouched by the current test suite.
We could also use some hypothesis tests. These may not be merged immediately as supporting hypothesis during the test build may be complicated, but writing hypothesis tests and running them locally may guide you to find some bugs or additional test cases that can be added to the standard test suite in the meantime.
In general, the documentation's organization needs to seriously improved. Some possible workflows for general documentation improvements:
-
Navigate to the documentation and try to get a sense for what the module does, what it is capable of and how it works. If you are confused or find it hard to navigate, take note of this and see if it can be improved.
-
View either my PyGotham (slides) or PyBay (slides) talks and try to read the relevant sections of the documentation. If the documentation does not give you the same understanding as the talks, note how it might be improved.
-
Work through one or more of the documentation exercises, using only the dateutil documentation to guide you, and see where it falls short.
-
Go through the
__all__attribute in each of the modules and check it against the documentation. There are some completely undocumented classes and functions.