MS RFC 1：技术指导委员会指南¶
- 日期
2005／06／24
- 作者
Frank Warmerdam，独立
- 联系方式
Pobox.com上可了解有关Warmerdam的更多信息
- 状态
总结¶
本文档描述了MapServer技术指导委员会如何确定成员资格，以及如何决定MapServer技术问题。
简言之，技术团队对MAPServer-DEV提案的投票至少可供两天的审查，单一的否决权足以延迟进度，尽管最终大多数成员可以通过提案。
详细流程¶
提案由任何相关方（不仅仅是委员会成员）编写并提交到MapServer Dev邮件列表上进行讨论和投票。
在做出最终决定之前，提案必须至少在两个工作日内可供审查。
被访者可以投票“+1”，表示支持提案和支持实施的意愿。
被调查者可以投票“-1”否决一项提案，但必须在两天内提供清晰的理由和其他解决问题的方法。
投-0表示有轻微的分歧，但没有效果。0表示没有意见。A+0表示轻度支持，但没有效果。
任何人都可以对名单上的提案发表评论，但只计算技术指导委员会成员的投票数。
如果一个提案收到+2（包括提案人），并且没有否决权（-1），它将被接受。
如果一项提案被否决，并且不能修改以满足所有缔约方的要求，那么可以重新提交进行否决投票，其中表明+1的所有合格选民的多数足以通过该提案。请注意，这是所有委员会成员的多数，而不仅仅是那些积极投票的成员。
在讨论和投票结束后，提案人应宣布他们正在进行（接受提案）还是正在撤回其提案（被否决）。
主席有投票权。
主席负责跟踪谁是技术指导委员会的成员（可能作为CVS中TSC文件的一部分）。
委员会成员的增加和撤换以及主席的选择应作为向委员会提出的建议处理。
主席裁决投票有争议的案件。
什么时候需要投票？¶
任何可能导致向后兼容性问题的内容。
添加大量新代码。
更改子系统间API或对象。
程序问题。
何时应该发布。
任何可能引起争议的事情。
“技术”的界限¶
如果它涉及到代码的更改，那么它是技术性的。
如果它涉及到开发人员如何合作，那么它是技术性的。
如果它涉及到代码所有权的法律问题，那么它是技术性的。
如果它与文档或网站有关，则不是技术性的。
如果它与会议等事件有关，则不是技术性的。
观察¶
如果事情破裂，主席是最终的裁决者。
绝对多数原则可以用来推翻阻挠性否决，但在正常情况下，需要说服否决者撤回其否决权。我们正在努力达成共识。
预计将设立单独的“委员会”来管理会议、文档和网站。