Weather.gov 2.0
Weather.gov 正在重建为“Weather.gov 2.0”，在美国数字服务团队的合作下推出新的基于 Drupal 的站点和设计，目标是让 NWS 的预报和危险信息更容易被找到、理解并采取行动。评论者赞赏现有服务及其详尽的图形化预报和雷达循环，但担心新版本会为了更重的 JavaScript 界面和分析而牺牲简洁性、性能和直接数据访问。这个项目也凸显了公共天气数据治理、各机构之间的碎片化，以及不应过度与商业天气供应商竞争的政治压力等更广泛问题。
2024 年的技术栈：Drupal
- 几位评论者对 Drupal 在 2024 年仍然是选择感到惊讶，称这是一个“有意思的”或过时的选择。
- 有一条讨论认为 Drupal 的插件/主题架构“天生不安全”；也有人反驳说，任何运行任意第三方代码的 CMS 都面临类似的供应链风险。
- 也有人指出 Drupal 以 Symfony 为基础，与 Laravel 有许多现代相似之处，并强调许多政府网站已经在使用 Drupal，因为招聘和生态支持更容易。
政府开源协同
- 许多人希望能有一个统一的“usa-gov”风格 GitHub 组织，把所有联邦 OSS 都列出来。
- 现有的一些部分解决方案被提到：code.gov、government.github.com，以及各个机构/组织各自的仓库。
- 有人提到 code.gov 最初通过
code.json实现的统一索引，因为资金和政策变化而逐渐衰退。 - 有人建议使用 GitLab 和自托管方案，并采用分层组织结构，但也有人认为让所有政府代码都集中在一个代码托管平台上并不现实；一个跨平台目录会更可取。
Weather.gov 的使用、API 和第三方工具
- 许多人依赖 weather.gov 作为一个简洁、无广告、稳定的数据源，尤其是在 Dark Sky 关闭之后。
- 有人分享了使用 api.weather.gov 或其他开放 API（如 Pirate Weather）制作的自建仪表盘和克隆站点。
- 评论者非常看重 Area Forecast Discussion 和图形化预报产品，认为它们独特地诚实且详细。
- 有人希望 2.0 更强调 API 和最后一公里工具，尤其是面向应急管理和专业用途；据说 api.weather.gov 不在这个项目范围内。
雷达、UX 与可访问性
- 之前那次“重大雷达更新”被广泛批评为缓慢、复杂、JS 负担重，并且不如旧的 GIF 循环。
- 也有人为 radar.weather.gov 辩护，认为它速度快、无广告，并且在许多设备上效果良好。
- 大家很欣赏旧版 GIF 循环（国家级和本地级）仍然存在，尽管不容易发现。
- 还有人担忧其渐进增强做得很差，而且缺乏无 JS 可访问性。
治理、透明度与政治
- README 中坦率承认组织分工孤岛以及 Conway 定律的内容，被赞为罕见的透明表达。
- 一些人担心“反馈/监控”会被用来为分析脚本和 cookie 横幅找理由；也有人指出政府现有的 analytics.usa.gov 做法。
- 多条评论提到历史上存在政治压力，不希望 NWS 产品与商业天气公司竞争得太激烈，并担心会有人试图将预报私有化。
Weather.gov 2.0 的状态与未来
- 该项目正从原型阶段迈向 MVP；路线图目标大约在五月。
- 发现了 staging 和 beta 端点，但权威站点仍然是现有的 weather.gov。
- 有些人对此感到兴奋，认为它可以成为现代联邦数字服务的范本；也有人担心会出现“臃肿的 JS”重设计，从而削弱如今这些备受珍视、数据密集的页面。