Open questions
Nine things I need from Colibrity to finish this properly. None of them block the draft - it ships with the assumption marked, and gets corrected when the answer arrives.
Marked assumptions are listed at the bottom so it is clear what is currently a guess.
1. The rest of your internal practices
The brief gave two examples: filters updating URL parameters, and page numbers in the URL. Both are
written up now. But two examples is not a house style, and the colibrity section of the standard
is currently the shortest one in the document.
Either send the rest, or point me at two recent projects plus their code review comments and I will reverse-engineer the conventions from them. The second option is usually more accurate anyway, because house rules tend to live in review comments rather than in documents.
2. Pagination, or load-more?
Worth being precise about, because it changes what gets built rather than just adding a parameter.
The current listings use an offset load-more button. That pattern has no pages, so there is no page number to put in a URL, and everything past the first batch is invisible to search engines.
I have specified: real server-rendered pagination at /page/2/ with proper links, and load-more
kept on top of it as an enhancement. That satisfies the rule and keeps the interaction. It is more
work than adding a parameter. Confirm this is what you meant.
3. Whose base do your developers start from?
The standard is written for the WordPress theme stack. If some of your projects start from a different base, or are not WordPress at all, tell me now - rules carry a stack marker, so a second stack is additive rather than a rewrite, but only if I know before I write the second half.
4. Staging environments
Is there a staging environment that matches production's headers, caching and CDN?
Several checks are meaningless otherwise. Compression, cache headers and performance measured against a staging box with a different configuration tell you about the staging box.
5. What do I receive for a review?
URL only, or URL plus repository plus an admin login? See "What I need to review a project" in HOW-THIS-RUNS. Anything missing gets reported as unverified rather than as a pass, so this mostly decides how much of each report is useful.
6. Any public sector or large-scale French clients?
This one genuinely changes the accessibility section.
The pass bar is currently WCAG 2.1 AA, which is the European Accessibility Act floor and covers private-sector clients. French public-sector bodies are held to RGAA 4.1 plus a published conformance declaration and a multi-year accessibility plan, which is a materially higher bar.
If public sector work is coming, tell me before I finish that section.
7. Who signs a waiver, and does a FAIL actually block?
When a required item cannot be met, whose written approval waives it?
And the real question underneath: if I mark a project not production ready, does that stop it shipping, or is it advice? Both are workable. They are different jobs, and the document should say which one it is.
8. Volume and turnaround
How many projects a month do you expect to send through this?
I have written two business days for a first review and one for a re-review. That is sustainable at a few projects a month. At a higher volume the automation in phase two stops being an improvement and becomes a requirement, which changes the timeline.
Also: is review time inside the framework rate, or scoped per project alongside the build? I have assumed the latter.
9. ClickUp access, so the template and the feedback can live in your workspace
I have guest access to your ClickUp with one list shared, DriveBerry Website. A guest cannot create Spaces or Lists, which blocks both of the things we discussed putting there.
What I would build, given member access:
- A feedback list with a public form, so comments on this document land as tasks instead of emails. Each rule and each question here gets a link that fills in what it is about, so anyone reviewing needs no ClickUp account and no login - they type the comment and it arrives already tagged with the rule, the page and their name.
- The project template for future projects, generated from the same rules, so the checklist a developer works through is the one this document describes rather than a retyped copy.
So: could you give me member access, or tell me who to ask? If you would rather keep access as it is, the alternative is that I host the feedback form in my own workspace and you get the link - that works fine, it just means the review history lives on my side rather than yours.
Until this is settled the comment links open an email, which works but makes me the middleman.
Assumptions currently baked into the draft
Each of these is what the document says today, and each is cheap to change.
| Assumption | From |
|---|---|
| WordPress, the shared theme stack | Q3 |
| WCAG 2.1 AA is the pass bar | Q6 |
| Real pagination with load-more layered on top | Q2 |
| Two business days first review, one for a re-review | Q8 |
| I report, your developer fixes, I re-check | Q7 |
| Review time scoped per project | Q8 |
| New projects only, nothing retroactive | - |
| English | - |
| Feedback goes to a ClickUp form, once we agree the workspace | Q9 |