docs(Goal): provide ETA and ensure Specs presents#51
Conversation
Signed-off-by: Vadim <vadim@holdex.io>
zolotokrylin
requested review from
angelicawill,
georgeciubotaru,
lwtsn,
markholdex and
matthewvogas
WalkthroughThe pull request updates the Changes
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
.github/CONTRIBUTING.md (4)
22-25: Consider using proper list numberingThe list currently uses "1." for all items. Consider using proper sequential numbering (1, 2, 3) for better clarity.
-1. analyze specifications (the Specs), -1. assess progress and outstanding Problems and -1. provide an estimated time of achieving (ETA) the Goal. +1. analyze specifications (the Specs), +2. assess progress and outstanding Problems and +3. provide an estimated time of achieving (ETA) the Goal.
91-94: Enhance design documentation guidelinesConsider adding:
- Examples of good vs. bad design documentation
- Specific instructions for linking DESIGN.md in README.md (e.g., section placement, link text)
Would you like me to propose example snippets for these additions?
Line range hint
4-147: Consider enhancing document structureThe document is well-organized but could benefit from:
- Adding warning blocks for critical requirements (e.g., time reporting, Specs requirements)
- Using consistent formatting for all requirement sections
- Adding a table of contents for easier navigation
Would you like me to propose a revised structure?
Line range hint
4-147: Maintain consistent terminologyConsider standardizing:
- Use of "Specs" vs "specifications"
- Use of "PR" vs "Pull Request"
- Capitalization of key terms throughout the document
Would you like me to list all instances where terminology should be standardized?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/CONTRIBUTING.md(4 hunks)
🔇 Additional comments (3)
.github/CONTRIBUTING.md (3)
27-27: Specify format requirements for Specs and ETAThe requirement for Specs and ETA should be more specific:
- What format should the ETA be in? (e.g., date, timeframe)
- What are the minimum required sections in the Specs document?
- What level of access should be granted in the Google Doc? (view/comment/edit)
Would you like me to propose a more detailed specification for these requirements?
147-147: Specify time reporting requirementsThe requirement to report time should be more specific:
- Where should contributors report the time? (e.g., PR description, comment)
- What format should be used? (e.g., hours, days)
- Should it be broken down by development phases (planning, implementation, QA)?
Would you like me to propose a structured format for time reporting?
Line range hint
4-147: LGTM with suggestions for enhancementThe changes improve the contribution guidelines and add important requirements. The suggestions above would further enhance clarity and usability, but the current version is already a significant improvement.
|
@angelicawill |
5 participants
Summary by CodeRabbit