Questions, from the work.
What does Flagholm actually do?
We put a change behind a switch. A few people see it. One number says whether it goes to everyone or comes back off. When the change is in, the flag is removed.
Why not just ship it?
Shipping a change should not take a meeting, and it should not hit everyone in the same minute. The code can go out dark. The flag is the release.
Why is the gift note still off?
Nobody has named the number that would turn it on. We will not add a flag so a meeting can invent that number later.
Why is receipt copy only on half of orders?
Half was enough to watch tickets. Tickets stayed flat, so it stays out at half. It is not a permanent costume. It goes wider when we would not take it back, and then the flag comes out.
The delivery window came off. Did the release fail?
No. Late orders rose, so the switch came off. Customers have the old window. That is the job. A flag that cannot come off is just a deploy with extra steps.
Who turns it off?
One owner. They do not call a meeting. The record says who flipped it, so the question has an answer later.
What if you never delete the flag?
Then it becomes a setting nobody owns. Name the flag for the change. When the change is in, delete the name.
What if Flagholm does not answer?
The app keeps the last answer. If it never had one, the flag stays off, which is the old behavior. A blank screen is worse.
Can a flag save a change that was not wrapped?
No. If the new path is the only path, the switch has nothing to return to. Wrap it, then deploy.
How do we start?
Write to [email protected]. Say the change, the few people who should see it, the number, and the person who may turn it off. If you do not have the number yet, you are in the gift-note case. Name it first.