Repository navigation
Development workflow #8
Description
Development doesn't equal coding, we develop to have a product.
Development is a process to make a requirement into implementation.
A requirement could be feature or bug fixing, enhancement, etc.
Mostly, implementation will be the code.
Then, it's a must to make sure our implementation is correct and suitable.
The result will be published in development-workflow.md under ``
Activity
[-]development workflow[/-][+]Development workflow[/+]xiaoland commentedon Mar 21, 2024
Got An Idea
The idea can be enhancements or new features, but not a fix.
xiaoland commentedon Mar 21, 2024
From the Product Requirement Document
Almost the same as the above, but be aware of these:
xiaoland commentedon Mar 21, 2024
Bug Report
A behavior acts abnormally or finds vulnerabilities.
Almost the same as the above, but be careful with these:
xiaoland commentedon Mar 21, 2024
懒得写英文了...
执行开发任务
或者说写代码
关于gitworkflow这块就不用多说了
这里主要是说如何进行开发与开发完成之后的PR处理
这里是组织全局性的，只制定一个大体的框架要求，具体的细节在每个项目的文档或者readme，guide中实现
xiaoland commentedon Mar 22, 2024
development/workflow.mdxiaoland commentedon Mar 24, 2024
...
Everything will be fine with development going...
Just remember to use tools, and make devOps
xiaoland commentedon Oct 26, 2026
Triage update: the organization now has Git/GitHub Governance, Contributing, and repository delivery workflows. The earlier comment also records completion of the workflow documentation. Concrete improvements to public entry points, issue triage, and PR handoffs are tracked in .github#39, with rule changes in #36.
This issue remains a historical design source. Next, coordination contact @xiaoland should identify any development behavior still missing beyond #39, with a scenario, expected result, and acceptance check. If no independent work remains, it can be resolved as superseded by the current rules. Until then, it is marked
needs-inforather than offered as a task to pick up.xiaoland commentedon Oct 26, 2026
The workflow-documentation outcome is now covered by the canonical Governance, Contributing, and Testing policy, with repository-local setup and delivery owners. The earlier checklist already records completion of the original workflow document.
Closing this documentation task as completed. Remaining public entry points and PR handoffs have an explicit owner and acceptance boundary in #39 and #36. This does not declare those pending deliveries complete. If a specific workflow behavior is still missing, open a focused task with its trigger, expected outcome, and acceptance check; this thread remains the historical design source.