ift-ts:web:ift:2026q3-maintenance
Description
Maintenance vs duty. These two commitments are complementary but not the same:
- Duty rotation answers who is “on call” for communication channels this week: first response, triage, classifying bugs vs feature requests vs questions, filing or routing issues, and protecting teammates’ deep-work time. Duty is about throughput of inbound signal, not about personally fixing every item during that week.
- This maintenance commitment is the actual engineering and follow-through on already-delivered web work if duty cannot keep up: dependency and security updates, CI/deploy and platform reliability, implementing fixes and small improvements from the backlog, documenting support outcomes, logging work for planning, and shipping hotfixes when production issues require code or config changes. Maintenance is scheduled, executed work on shipped properties—not defined by the duty calendar.
The Web unit keeps previously delivered applications, sites, and tools healthy across the IFT ecosystem.
The maintenance commitment supports IFT’s strategic objectives by:
- Project Sustainability: Shipped products stay secure, compatible, and operable
- User Experience Continuity: Regressions and rough edges are addressed deliberately
- Technical Debt Management: Post-launch issues are fixed or tracked rather than forgotten
- Clear handoff from duty: Issues triaged on duty land here (or in project backlogs) as concrete maintenance work
Task List
Maintenance
- fully qualified name:
ift-ts:web:ift:2026q3-maintenance:maintenance - owner: unassigned
- status: not started
- start-date: 2026/07/01
- end-date: 2026/09/30
Description
Execute upkeep across delivered web properties for Q3: dependency and security bumps where needed; CI, preview deploy, and hosting workflows; bugfixes and small improvements that come from backlog, support, or duty triage; GitHub hygiene (issues, labels, planning links); urgent hotfixes when production is affected. Coordinate with duty so inbound items become tracked work here rather than orphaned chat threads.
Deliverables
- Merged fixes and improvements on shipped repos (PRs as appropriate)
- Stable CI/deploy and platform operations for maintained properties
- Support and stakeholder questions addressed or documented with clear next steps
- Issues created or updated for planning; hotfixes verified and briefly recorded
Merge Vercel teams under IFT-TS
- fully qualified name:
ift-ts:web:ift:2026q3-maintenance:merge-vercel-teams-ift-ts - owner: Felicio
- status: not started
- start-date: 2026/07/01
- end-date: 2026/07/24
Description
Consolidate the two Vercel teams the Web unit currently uses into a single team named IFT-TS (IFT Technical Services). Vercel confirmed teams can’t be merged literally; instead, keep one as the recipient, migrate the other team’s projects and domains in, then rename the recipient. Their recommendation captured in the support thread:
Why also (besides one team to manage): members who currently sit on both teams are billed twice under Vercel’s per-seat pricing. Consolidating to one team means each person counts as one paid seat, not two — straightforward cost reduction proportional to how many people overlap.
“It is not possible for us to ‘merge accounts or teams.’ You would need to create a new team and then migrate the projects and resources as you’d like. My recommendation would be to keep one of the teams, and then migrate all the projects and domains from the other team into the one you decide is the ‘main one.’ After that, you can rename the team.”
Pricing: per Vercel pricing — no special behaviour or rates for merged members. Switching to Pro: see Switching to Pro. No breaking changes expected.
Source teams:
Plan (per Vercel):
- Pick the recipient team (proposed:
status-im-web— larger project inventory; confirm before migrating). - Inventory projects, domains, env vars, integrations, deploy hooks, and team members on both sides; flag anything that needs special handling.
- Transfer projects from the other team into the recipient — project transfer docs.
- Transfer domains alongside or after each project — domain transfer docs. Watch DNS / TLS continuity.
- Re-add integrations, env vars, deploy hooks on the recipient as needed; verify CI / preview deploys per project after move.
- Switch the recipient to the new Pro plan if not already on it — Switching to Pro.
- Rename the recipient team to
IFT-TS(slugiftif available; otherwiseift-ts). Update any hardcodedvercel.com/<team>references in docs / READMEs / CI. - Close the now-empty source team.
- Announce the change to project owners and anyone with deploy access.
Deliverables
- Inventory note (projects, domains, env vars, integrations, members on both teams) with migration mapping
- All projects + domains moved to the recipient team; per-project sanity check that deploys + previews + custom domains still work
- Recipient team switched to the right Pro plan
- Recipient team renamed to IFT-TS (
vercel.com/iftorvercel.com/ift-ts) - Source team closed
- Brief operator note: who/what to ping for Vercel access under the new team, including the support-thread context
Merge Figma teams under IFT-TS
- fully qualified name:
ift-ts:web:ift:2026q3-maintenance:merge-figma-teams-ift-ts - owner: Felicio
- status: not started
- start-date: 2026/07/01
- end-date: 2026/07/24
Description
Consolidate the Figma teams the Web unit currently uses into a single team named IFT-TS (IFT Technical Services), mirroring the same change being made on Vercel (merge-vercel-teams-ift-ts above). One team means a single source of truth for files, projects, libraries, and member access.
Deliverables
- Inventory note (projects, files, libraries, plugins, members on both teams) with migration mapping
- All projects + files moved to the recipient team; per-project sanity check that shared libraries, prototypes, comments, and Dev Mode handoffs still work
- Recipient team renamed to IFT-TS