Loading
A forked improvement creates an improved version based on an existing project. This guide explains how to choose a base version, fill in the improvement goal, specific changes, rationale, advantages, and new risks, and when to use a fork versus a structured review.
Forked improvements are suitable for: - You've seen a project and believe you can make specific improvements to it. E.g. the original kitchen layout isn't efficient enough, and you have a better layout solution. - You want to try a different design direction. E.g. the original took a "storage-first" approach, and you want to try an "open layout + lighting" approach. - Someone pointed out an optimizable direction in a structured review, and you want to implement that optimization. The difference between forked improvements and structured reviews: - Structured review: you only provide text feedback, not a new design proposal. - Forked improvement: you create a new design version based on the original, including specific changes and a new proposal description. If you just want to give feedback without creating a new proposal, use a structured review. If you have a concrete improvement plan, use a forked improvement.
Before creating a forked improvement: 1. Browse the entire original project page: carefully review the design goal, summary, highlights, areas for improvement, project images, version tree, and existing reviews. Understand the original proposal's design logic and existing feedback. 2. Be clear about what you want to optimize: improving circulation, adding storage, adjusting materials, optimizing budget allocation, or trying a completely different design direction? The more specific the goal, the more valuable the fork. 3. Prepare your change description: what specifically was changed, why, what advantages the new proposal has over the original, and what new risks may be introduced. 4. Prepare new proposal images: if you have new floor plans, renders, or supporting images, you can upload them in the fork. 5. Check the original project's license: if the original project chose "display only all rights reserved", forks are not allowed. You can only fork when the original project permits it.
The fork page contains the following fields: - Fork title: e.g. "Kitchen circulation optimized + storage enhanced", "Open layout + lighting redesign". The title should reflect your improvement direction. - Contributor: your name or team name. - Contact email: for platform review and communication only, not publicly displayed. - Improvement goal (required): clearly describe the core objective of this fork. E.g. "while preserving the original proposal's storage system, optimize kitchen-to-dining circulation, reducing walking distance from prep to serving". Don't just write "made an improved version". - Specific changes (required): detail the specific modifications relative to the original. E.g. "replaced the solid wall between kitchen and dining with a glass sliding door for visual transparency; moved the refrigerator from the kitchen corner to the dining side, freeing 600mm of kitchen counter space; added a 1.2m buffet sideboard in the dining area". - Rationale (required): explain why these changes were made. E.g. "the original kitchen counter was only 2.4m, insufficient for a family that cooks frequently. Moving the refrigerator frees 600mm of counter space for food prep. The glass sliding door can be closed to block cooking fumes when needed, and opened to maintain spatial flow". - New proposal advantages: describe the benefits relative to the original. E.g. "kitchen counter increased from 2.4m to 3.0m; walking distance from kitchen to dining table reduced from 5m to 2m; added buffet sideboard in dining area improves meal convenience". - New risks or trade-offs (required): honestly describe risks the new proposal may introduce. E.g. "glass sliding door has poorer sound insulation than a solid wall — kitchen noise may affect the living room; moving the refrigerator reduces dining area by ~1.5㎡; glass sliding door requires regular cleaning, higher maintenance than a solid wall". - Desired review direction: what aspects you'd like reviewers to focus on, e.g. "please focus review on whether the kitchen circulation is reasonable", "please evaluate the glass sliding door's effectiveness at blocking cooking fumes". - Proposal images: upload new floor plans, renders, or supporting images. Three confirmation checkboxes at the bottom must be ticked: confirm the fork does not change the original project, confirm you have publishing rights or authorization for the new proposal, agree to Terms of Service, Privacy Policy, and Content License Agreement.
After submission, the page shows a "Submitted for review" screen listing the fork title, contributor, improvement goal, specific changes, rationale, advantages, and new risks. After submission, confirm the following: 1. Is the improvement goal specific and measurable? 2. Do the specific changes describe item by item what was changed? 3. Does the rationale explain why each change was made? 4. Do the new risks honestly list the potential trade-offs? 5. Are all three confirmation checkboxes ticked, especially "confirm the fork does not change the original project"? You can check your submission status on your account page (/zh/account or /en/account). Once approved, the forked improvement will be displayed in the version tree. Note: a forked improvement does not change the original project, only creates a new branch. Your fork will appear in the original project's version tree as an independent node.
Here are the most common mistakes when creating a forked improvement: 1. Improvement goal too vague: writing "made an improved version" or "some improvements" without specifying what was improved. 2. Changes don't compare to the original: only describing what the new proposal does, not what changed relative to the original. The core value of a fork lies in the comparison. 3. No rationale: only writing "changed the kitchen layout" without explaining why. Changes without reasoning cannot be reviewed. 4. No new risks: pretending the new proposal is flawless. In reality, any change may introduce new trade-offs — honestly stating them demonstrates professionalism. 5. Not checking the original project's license: if the original project doesn't allow forks, you cannot create one. 6. Treating a fork as a brand new project: a fork should clearly indicate which project and version it's based on, not pretend to be entirely original. 7. Changes unrelated to the original: a fork should be built around the original project's design goals, not be a completely unrelated new proposal.
A forked improvement is a derivative work based on someone else's contribution. Please respect the original author's contribution and license boundaries: 1. A fork does not change the original project, only creates a new branch. The original project remains unchanged. 2. The fork title and description should clearly indicate which project it's based on. 3. If the original project chose "display only all rights reserved", forks are not allowed. 4. Images uploaded in a fork should be your own work or authorized work — do not directly copy images from the original project. 5. If you've made substantial improvements to the original, you can describe them in the advantages section, but should not disparage the original. See the Content License Agreement and Community Guidelines for detailed rules.