不管您遵守哪一套规则，如果它们与 PEP 8 有出入，那么我建议提供相关文档使那些参与您项目的人了解您所使用的代码样式。最好是显式表达，而不是隐式表达。
pyflakes 是一款非常有用的 linter 工具。它能很好地实现功能、捕捉与高亮显示错误之间的平衡，而无需过多奇怪操作。下面是一个在 Python 项目上使用 pyflakes 的示例会话：
$ pyflakes kaleo kaleo/forms.py:1: 'form' imported but unused kaleo/forms.py:4: undefined name 'forms' kaleo/forms.py:6: undefined name 'forms'该工具会立刻告诉我有一个输入拼写错误。查看 kaleo/forms.py，我看到：
1: from django import form 2: 3: class InviteForm(forms.Form): 4: email_address = forms.EmailField()...告诉我将第 1 行更改为 from django import forms。
对项目进行测试以验证代码的运行情况总是很有帮助的，这样可预防忽略回归 (regressions)，并在某些情况下它可作为一种文档格式，在其中阅读测试代码可以告知其他人库中的 API 工作情况。
也就是说，我不会根据项目是否包括测试或这些测试的完整程度来判断一个项目的完整性和可行性。测试的存在并不能保证代码的质量。这也许是一个具有争议的观点，但是我个人认为完全不进行测试总比测试不当要好。在编写测试程序时，将各种输入放置到测试中的每个单元非常重要。
但是，与测试不同，您可以 根据项目文档的质量和范围来判断一个项目的质量和工艺。编写和维护文档的方法与您编写和维护代码的方法相似。文档写得出色并具有深度，可吸引更多的参与者加入，使用户更接近您的项目。
使用 Sphinx 和 Read the Docs等工具，您可以拥有已发布的最新文档，这些文档看起来非常棒。使用这些工具与编写词组并按提交一样简单。在合适时养成尽可能使用提交键来提交文档更改的习惯。
维护
发布了 Python Package Index (PyPI) 第一个版本，在各个 Tweet 和博客文章中宣布，并开始拥有一些用户后，您就需要对所有持续活动添加维护操作。用户将会报告 bug，请求特性，询问在文档中不明显的问题等。
有些事情您可以选择不做，并提出解决方法；但是对于其他一些事情，您可能想要在文档或代码中进行修改。使用 Git 等分布式版本控制系统 (DVCS) 并发布常用的开发人员软件包，可以简化有关维护的繁琐工作。
有多款分布式版本控制系统可用，其中包括 Git 和 Mercurial。不管您选择哪一版本的控制系统，请确保该系统提供源代码控制，可以让用户分享您的项目并自己修订 bug。
执行更改的速度取决于许多因素，其关键因素之一是目标受众（例如，其他开发人员和非技术性最终用户）。如果您正在为开发人员编写代码，那么鼓励在 pull 请求中提供 bug 报告或特性请求可以真正地减轻维护人员的负担。同时，它还能增强社区感，因为人们可以参与到未来发行版的构建中。
您希望在每次发布其他补丁集后尽早且频繁地多次发布开发版本。这样可以使其他在工作中使用您项目的开发人员更加轻松地运行项目的最新更改。在不同场景中使用代码的人越来越多，在发布新稳定版本时质量就越好。
维护随之而来的是支持。参与并构建一个由用户和参与者组成的社区至关重要。授权其他人帮助您提供支持，可提高项目的总体合作因素，使项目规模获得更好的扩展性并自然地加强解决用户问题的观点。
因此，确保提供多个通道以提高普及率并使用户能够更加轻松地参与您以及项目。通道选项包括 IRC、邮件列表和社交媒体（比如 Twitter）。
在 freenode 等 IRC 上建立通道是一个好想法。我就为自己的项目 nashvegas 建立了这样一个通道；虽然除了我没有别的用户，但是我的 IRC 客户端能在后台运行。当临时用户有问题时，我能够以很低的事务处理成本且更加动态的方式来回应此问题，而不是通过电子邮件。