OpenLake / OpenLake/OpenLake--Website
Create documentation for contributors
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 3
- Forks
- 16
- Avg merge
- 8h 54m
- Merged PRs (30d)
- 7
Description
Create documentation for contributors
This is a sub-issue of #15
Overview
Develop comprehensive documentation to guide contributors on how to submit new blog posts to our platform.
Tasks
- Write CONTRIBUTING_BLOGS.md guide with clear step-by-step instructions
- Create a blog post template file (blog-template.md) with example frontmatter
- Document all required and optional frontmatter fields with descriptions
- Provide examples for common Markdown formatting elements (headings, lists, code blocks)
- Include guidance on image inclusion and optimization
- Document the full contribution workflow (fork → create → submit PR)
- Add troubleshooting section for common issues
Contents for CONTRIBUTING_BLOGS.md
- Introduction and purpose
- Prerequisites (GitHub account, basic Markdown knowledge)
- Step-by-step contribution process
- Frontmatter fields reference
- Markdown formatting guidelines
- Media inclusion guidelines
- Sample blog post examples
- Submission checklist
- Troubleshooting
Definition of Done
- Documentation is clear, comprehensive, and beginner-friendly
- Blog template file is created and well-commented
- All frontmatter fields are properly documented
- Media handling instructions are clear with examples
- Documentation is reviewed for accuracy and completeness
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the requested CONTRIBUTING_BLOGS.md outline and blog-template.md tasks, using the issue checklist to organize the frontmatter, Markdown, media, workflow, examples, and troubleshooting sections. Done means both files exist, the required fields and contribution steps are documented with beginner-friendly examples, and the definition-of-done review confirms accuracy and completeness.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github, markdown
- Domain
- content, documentation
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 58/100