ken.li
3525aee49e
新增中间件相关文档包括 RocketMQ、Nacos、PowerJob 的部署指南和故障分析文档，完善 Keepalived 和 MySQL 的文档内容。新增内部通讯技能模板和示例文件，包括 3P更新、公司通讯、FAQ回答等格式指南。优化服务文档结构，补充 FIX 引擎高可用架构说明。新增中间件综合指南，详细说明高可用部署方案和灾备转换原理。 新增 RocketMQ 5.3.2 集群部署文档，包含 Controller 模式详解和详细配置说明。新增 Nacos 和 PowerJob 部署文档，补充服务依赖和关键配置。更新 MySQL 故障分析文档，优化复制冲突解决流程。新增内部通讯技能模板文件，规范公司内部通讯格式。 docs: 补充服务文档和中间件 TODO 列表 新增 g3fo-exchange-fix-engine-service 服务文档，详细说明服务职责和关键配置。新增中间件 TODO 列表，跟踪待补充的文档内容。更新 Keepalived 部署文档，新增主库抢占前置检查脚本和配置说明。优化中间件文档结构，补充常见问题和性能优化建议。 style: 统一文档格式和代码块样式 统一所有文档的代码块格式和标题层级。优化表格显示样式，增强可读性。规范环境变量和配置项的显示方式。调整文档结构，确保逻辑清晰。修复部分拼写错误和格式问题。 chore: 新增 LICENSE 文件 新增内部通讯技能的 Apache 2.0 LICENSE 文件。补充文档版权信息。更新文件头部的元数据描述。规范文件命名和目录结构。
47 lines
3.2 KiB
Markdown
47 lines
3.2 KiB
Markdown
## Instructions
|
|
You are being asked to write a 3P update. 3P updates stand for "Progress, Plans, Problems." The main audience is for executives, leadership, other teammates, etc. They're meant to be very succinct and to-the-point: think something you can read in 30-60sec or less. They're also for people with some, but not a lot of context on what the team does.
|
|
|
|
3Ps can cover a team of any size, ranging all the way up to the entire company. The bigger the team, the less granular the tasks should be. For example, "mobile team" might have "shipped feature" or "fixed bugs," whereas the company might have really meaty 3Ps, like "hired 20 new people" or "closed 10 new deals."
|
|
|
|
They represent the work of the team across a time period, almost always one week. They include three sections:
|
|
1) Progress: what the team has accomplished over the next time period. Focus mainly on things shipped, milestones achieved, tasks created, etc.
|
|
2) Plans: what the team plans to do over the next time period. Focus on what things are top-of-mind, really high priority, etc. for the team.
|
|
3) Problems: anything that is slowing the team down. This could be things like too few people, bugs or blockers that are preventing the team from moving forward, some deal that fell through, etc.
|
|
|
|
Before writing them, make sure that you know the team name. If it's not specified, you can ask explicitly what the team name you're writing for is.
|
|
|
|
|
|
## Tools Available
|
|
Whenever possible, try to pull from available sources to get the information you need:
|
|
- Slack: posts from team members with their updates - ideally look for posts in large channels with lots of reactions
|
|
- Google Drive: docs written from critical team members with lots of views
|
|
- Email: emails with lots of responses of lots of content that seems relevant
|
|
- Calendar: non-recurring meetings that have a lot of importance, like product reviews, etc.
|
|
|
|
|
|
Try to gather as much context as you can, focusing on the things that covered the time period you're writing for:
|
|
- Progress: anything between a week ago and today
|
|
- Plans: anything from today to the next week
|
|
- Problems: anything between a week ago and today
|
|
|
|
|
|
If you don't have access, you can ask the user for things they want to cover. They might also include these things to you directly, in which case you're mostly just formatting for this particular format.
|
|
|
|
## Workflow
|
|
|
|
1. **Clarify scope**: Confirm the team name and time period (usually past week for Progress/Problems, next
|
|
week for Plans)
|
|
2. **Gather information**: Use available tools or ask the user directly
|
|
3. **Draft the update**: Follow the strict formatting guidelines
|
|
4. **Review**: Ensure it's concise (30-60 seconds to read) and data-driven
|
|
|
|
## Formatting
|
|
|
|
The format is always the same, very strict formatting. Never use any formatting other than this. Pick an emoji that is fun and captures the vibe of the team and update.
|
|
|
|
[pick an emoji] [Team Name] (Dates Covered, usually a week)
|
|
Progress: [1-3 sentences of content]
|
|
Plans: [1-3 sentences of content]
|
|
Problems: [1-3 sentences of content]
|
|
|
|
Each section should be no more than 1-3 sentences: clear, to the point. It should be data-driven, and generally include metrics where possible. The tone should be very matter-of-fact, not super prose-heavy. |