目标
上面所指出的问题中每一个都可以转换成高层次的目标. 其中一些可以比其它更加容易和快速的达成.
一个重要的原则就是，对这些目标的关注，以及它们的优先级，都将在交付新特性这一任务之上.
RT 解压
用一种设定时间线的方式将所有新提交的RT项都管理起来，比如在四个工作日之内要做出初步的响应. (时间刻度: 现在)
RT积压要随着时间逐步减少 (时间刻度: 正在进行).这可能会包含大量尘封已久的非常老的RT项， 比如那些比任何当前支持版本都要早提交的RT项
不完整/错误的文档
为所有公共的API提供完整的文档（不包括过时的API）（时间线：一年之内)
这可能要引入一个新的文档系统
API的一些部分历史上曾是公共的，但并不打算供公共使用, 比如低级别的加密和摘要API. 这些部分可能没有文档, 或者可能要打上过时的标记(时间线: 9个月之内).
复杂的库
审查并修订公共API，以降低其复杂度 (时间线：一年之内)
提供一份平台战略文档：见下文(时间线：三个月之内)
审查并重构FIPS的代码，降低其受侵扰的程度(时间线：一年之内)
审查并重构内存管理的代码(时间线：六个月之内)
不一致的代码风格
为项目制定一个明确的编码标准。它不仅将涵盖代码布局，还将涉及如何处理平台依赖，单元测试以及可选代码这些项目（时间线：三个月之内)
根据通过的标准格式化整个代码库. (时间线：在编码标准被明确的三个月之内)
依照风格指南的其它部分重构代码. (时间线：一年之内)
代码审查
商定并实现一个流程，以便所有新的提交都能首先被熟悉相关代码的团队成员更新，直到审查者提出的问题被解决. 这需要招募足够多的团队成员来使得代码审查或多或少总是能维持下去. (时间线：三个月之内)
商定一个代码审查系统. (时间线：六个月之内)
审计
要有对当前代码库的外部审计. (时间线：依赖于外部主体)
静态/动态分析
采用合适的工具定期对代码进行审核. (时间线：六个月之内)
