RFC 9:GDAL付费维护者指南
作者：弗兰克·温特丹
联系方式：warmerdam@pobox.com
Status: Approved, but superseded per RFC 83: guidelines for the use of GDAL project sponsorship
目的
正式制定由GDAL项目赞助基金支付的维护人员工作指南。
责任
分析并在可能的情况下修复针对GDAL报告的错误。
运行、检查和扩展测试套件（通过buildbot等）。
维护和扩展文档。
协助整合新贡献的功能。
帮助维护项目基础设施（邮件列表、buildbot、源代码管理等）
在项目邮件列表和其他场所提供用户支持。
开发新的能力。
错误修复和维护应该集中在GDAL/OGR上，但如果需要，将扩展到libtiff、libgeotiff、Shapelib和MITAB等子项目中，只要它是为了满足GDAL/OGR项目的需要。
为了提供合理的响应时间，希望维护人员每周花一些时间解决新的bug和用户支持。如果维修人员长时间不在（休假等），则应通知主管。
方向
维护人员通常服从项目PSC。但是，对于日常决策，将指定一名PSC成员作为维护人员的主管。该主管将通过电子邮件、错误分配和IRC讨论确定工作的优先级。
主管在确定任务优先级时，会尽量记住以下几点。
Bug报告和赞助商的支持需求应该比其他任务得到更高的优先级。
PSC确定的重点领域（即多线程、SWIG脚本）应该比其他任务具有更高的优先级。
影响许多用户的bug或需求应该具有更高的优先级。
维修人员应负责其他人不愿意和不能做的工作（即填补漏洞，而不是替换志愿者）
Try to avoid tying up the maintainer on one big task for many weeks unless directed by the PSC.
维修人员不应被指示做其他人得到报酬的工作。
实质性的新开发项目将只由维护人员在PSC运动的指导下进行（或者可能由RFC指定维护人员进行变更）。
请注意，对于GDAL的任何实质性更改，维护人员和维护人员主管都要遵守正常的RFC流程。
报告
维护人员将每两周向gdal dev列表生成一份简短的报告，指出已处理的任务，并为主管生成一份更详细的时间表。
这是为了提供状态、成就和时间分配的可见性。这也为PSC提供了一个相当迅速地请求“航向修正”的机会。