社区指南
参与 SQLAlchemy 及其相关项目的指南。
虽然这些部分可能是针对 SQLAlchemy 核心项目的开发者编写的，但各种指南，特别是行为准则，适用于 SQLAlchemy 组织存储库下托管的所有项目。
参与
项目状态
参与的关键是关注项目的当前状态。 SQLAlchemy 的当前发布版本始终位于主页右侧顶部。 通常，一次会发布两个**分支**，例如“1.3”和“1.4”。 较高的数字，即“1.4”，是“默认”分支，而“1.3”是“维护”分支。 迁移到一对新的主要分支大约需要 12-18 个月。 我们缓慢而稳步前进的方法迄今为止对项目非常有利，允许在接纳更多新用户之前在架构和使用方面取得巨大进步。
可以通过查看 GitHub 项目页面 来了解开发的总体状态。 我们尝试将所有错误和新功能分配到特定版本，这些版本链接到里程碑。 特定数字，如“0.6.8”，意味着我们希望在该版本完成该问题（尽管这并非总是保证）。 像“0.7.xx”这样的“开放式”数字意味着该问题“在队列中”，但尚未确定为任何特定版本的一部分。 其中许多问题优先级较低，有些问题也很复杂且繁琐，并且会随着主要版本的推进而被推动，在某些情况下会推动多次。 你可以 帮助解决 其中一些问题！
GitHub
SQLAlchemy 使用 Github 进行错误报告和问题跟踪、讨论、Wiki 页面以及公共源代码访问。
报告错误
错误报告通过 GitHub 进行。
我们强烈建议将使用问题首先作为 Github 讨论 报告，而不是作为问题报告。 随着从问题描述中识别出问题，SQLAlchemy 开发人员将根据需要打开要修复的问题。
在报告行为（非文档）错误时，我们要求您
创建一个简洁的测试用例来重现问题。 这需要是一个我们可以实际运行的脚本 - 所以它不应需要任何 SQLAlchemy 开发人员无法访问的导入，并且在绝大多数情况下不应有任何除了 SQLAlchemy 本身之外的导入。 它需要包含任何表定义和数据，以便重现问题。 虽然我们可以访问大多数数据库后端，但如果问题不是特定于某个后端，则首选 SQLite。
我们为此使用的指南是 StackOverflow 上的 如何创建最小化、完整且可验证的示例。 请阅读一下。
- 至少，如果代码示例不可行，请包含所观察到的所有异常的完整堆栈跟踪。 没有堆栈跟踪，异常消息就变得模棱两可了。
- 告诉我们观察到问题时 SQLAlchemy 的确切版本，以及有关所使用数据库的信息以及所使用的确切驱动程序（例如 Python DBAPI）。
- 请回复针对该问题的后续问题。 如果我们无法获得所需的其他信息，我们通常必须关闭该问题。
报告安全问题
SQLAlchemy 参与 Tidelift 安全基础设施，以便负责任地报告潜在漏洞。 请遵循 Tidelift 安全 中的指南，以报告安全问题。 SQLAlchemy 中的安全问题非常罕见，在十四年内只报告过三个 CVE。 尽管如此，我们还是希望您在先给我们发邮件之前不要提交 CVE，以便可以采取适当的披露步骤。
用户帮助
SQLAlchemy 始终需要人们来帮助回答问题，尤其是来自新用户的回答。
有关当前 IRC/聊天区域的链接，请参见 实时频道。
SQLAlchemy 非常重视用户与开发者之间礼貌、周到和建设性的交流。 粗鲁、人身攻击或生硬的回答永远不合适，即使对于提出不合理请求的用户也是如此。 请参阅我们的 行为准则，了解完整的声明。 我们还尝试确保 Github 讨论中的任何消息都不会无人回复，即使答案只是礼貌地将用户引导到文档的适当部分。 SQLAlchemy 核心开发人员希望鼓励所有用户参与这项任务 - 如果您看到一个非常基本的问题在列表中停留了几天，那就是我们希望您能回复它！ 您有我们的许可 :).
