Here are some observations and possible tasks that arose from our experience at Pycon (both the sprints and conference proper)
- We made a number of personal connections in the Python community -- we are no longer a faceless corporate like entity
- Phil Gaudette in interested in continuing to develop and maintain the dump/restore code from the Sprint, as well as getting more involved
- Bear wants to be more involved and will start giving more feedback
- We got a good idea of where we are too hard / confusing / frustrating / not pythonic
- Attendance at the BOF shows that the buzz around Chandler remains -- attendance was around 30-40/320 people, so at least 10% of PyCon.
- Multiple people thanked me for OSAF turning out "in force" for PyCon and the sprints.
We are too hard / confusing / frustrating / not-pythonic
- Build system / system environment packaging
- There is confusion around the respository concepts and API
People are unaware that we have the basic resources common to decent open source projects including
- milestone builds
- CVS and commit lists
- mailing lists
The information on the wiki is too voluminous and hard to digest
- At least two people told me that they thought "Chandler was good at process and documents and not at code"
What needs to happen?
Improve awareness of our progress and status:
- We should adapt to the way that other Python/OSS projects make their info available
- Simple SourceForge like portal to critical resources (CVS, builds, mailing lists, wiki)
- We need to start announcing the availability of milestone releases outside of our own lists
- RSS feeds (which?)
- milestone releases should have changelogs (but not necessarily detailed release notes)
- Get involved with the CIA commit broadcasting system <http://cia.navi.cx/>
- Consider starting projects for the repository / libraries which we develop:
- pylucene -- the python bindings
- heikki's crypto stuff
Improve the build system / developer environment
- Ask a few python experts for their opinion on how to improve our build system and developer builds
- to make them easier for veteran Python programmers to use
- Refactor the Busy Developer's Guide and Extending Chandler into 3 separate but related documents
- Convert selected unit tests to use the doctest framework so that tests do double duty as sample code and tests
Selectively engage individuals in the various communities who can help us technically and lend us their credibility
- We cannot do this unless we are willing to accept feedback at face value - not be defensive
- This needs to happen at a technical level not a marketing level
- Ex: Anthony Baxter (shtoom/VOIP), DivMod (twisted)
Treat the platform aspects of Chandler as a product
- Include developer/platform features in the product plan
- Have periodic user testing around these features (that's part of what happened at the sprint)
Maintain momentum from the sprints
- A few of the sprinters want to continue on with the projects started there. How could we support them?
- A separate CVS repository that would be part of an incubator for Chandler related projects
Encourage additional OSAF staff developers to get involved with some part of the community
- Users groups, local sprints, etc.
- 26 May 2004