Changes for content/handbook/engineering/architecture/design-documents/artifact_registry/_index.md: 1 added line, 1 removed line.
Original line number
Diff line number
Diff line
@@ -403,7 +403,7 @@ TBD
|------|---------------|--------|-------------|
| **[Database Frameworks](/handbook/engineering/data-engineering/database-excellence/database-frameworks/)** | **Schema design**: Review schema proposed in [ADR-007](decisions/007_database_schema.md)-format-specific tables vs. cross-format operations, deduplication logic, blob reference tracking, access and cleanup patterns. **Sharding**: Validate sharding key. **Performance**: Query patterns for key operations, cleanup tasks, storage attribution. **Scale**: Validate for GitLab.com scale (billions of records, TB-range metadata). **Partitioning/isolation**: Table partitioning strategy and logical database isolation (new database alongside `main` and `ci`). | ADR-007 revised, expanded, and approved. | **Critical** - Large number of new tables with complex deduplication, reference tracking, and cleanup logic. Schema must be correct from the start; large-scale refactoring would be extremely costly. |
| **[Platform Insights](/handbook/engineering/data-engineering/analytics/platform-insights/)** | **ClickHouse/DIP integration**: Event collection patterns for artifact operations, schema design for analytics tables, query optimization for cost tracking and usage reporting. **Event instrumentation**: Patterns for capturing and storing long-term event records for audit and feeding AI/ML features (recommendations, optimization). | New ADR with strategy for event collection and processing. | **High** - Core value proposition includes cost analytics, usage tracking, and AI-powered insights. Getting this right from the start is key. |
| **[Fulfillment:Utilization](/handbook/engineering/development/fulfillment/utilization/)** | **Billing integration**: Billing model, integration with CustomersDot for invoicing and payment processing. **Storage quotas**: Quota enforcement patterns, usage tracking per organization, integration with existing consumables management. **Cost attribution**: Mechanisms for tracking and reporting storage costs. **Usage notifications**: Alert mechanisms when approaching limits. | New ADR with strategy for consumption tracking and usage billing. | **High** - New paid SKU requiring monetization. Without billing integration the product cannot be sold. |
| **[Fulfillment:Usage Visibility and Cost Management](/handbook/engineering/development/fulfillment/#teams)** | **Billing integration**: Billing model, integration with CustomersDot for invoicing and payment processing. **Storage quotas**: Quota enforcement patterns, usage tracking per organization, integration with existing consumables management. **Cost attribution**: Mechanisms for tracking and reporting storage costs. **Usage notifications**: Alert mechanisms when approaching limits. | New ADR with strategy for consumption tracking and usage billing. | **High** - New paid SKU requiring monetization. Without billing integration the product cannot be sold. |
| **[Geo](/handbook/engineering/infrastructure-platforms/tenant-scale/geo/)** | **Replication validation**: Confirm existing Geo Self-Service Framework can replicate all relevant registry data for self-managed and Dedicated installations. **Gap analysis**: Identify any limitations or additional work needed beyond the framework. | Update blueprint to confirm full compatibility. Follow-up issues for any gaps. | **Medium** - Early validation prevents costly rework and ensures feature parity across all installation types. |-->
Changes for content/handbook/engineering/architecture/design-documents/cdot_error_reporting/_index.md: 1 added line, 1 removed line.
Original line number
Diff line number
Diff line
@@ -37,7 +37,7 @@ A spike issue for the proposal can be found at gitlab-org/customers-gitlab-com#1
## Proposal
The [Fulfillment Platform group](../../../development/fulfillment/fulfillment-platform/) currently handles the manual process of monitoring the described errors. Each week, an engineer is assigned to a [Job monitoring issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/.gitlab/issue_templates/Job%20monitoring%20weekly.md?ref_type=heads), where they must gather a collection of errors daily by running a script. These errors are then reviewed individually to identify actionable items, such as those not related to user validation, payment method validation, or location issues. The engineer manually resolves these errors with the use of console or Admin panel.
The [Monetization Platform group](../../../development/monetization/#teams) currently handles the manual process of monitoring the described errors. Each week, an engineer is assigned to a [Job monitoring issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/.gitlab/issue_templates/Job%20monitoring%20weekly.md?ref_type=heads), where they must gather a collection of errors daily by running a script. These errors are then reviewed individually to identify actionable items, such as those not related to user validation, payment method validation, or location issues. The engineer manually resolves these errors with the use of console or Admin panel.
To improve efficiency and results, we need to automate this process.
The [Monetization](/handbook/engineering/development/monetization/) and [Fulfillment](/handbook/engineering/development/fulfillment/) sections share one way of working. Section specific content, including CustomersDot engineering and incident processes on the Monetization page, lives on each section page.
## Shared Slack channels
| Channel | Purpose |
|---------|---------|
| [#fulfillment_monetization_fyi](https://gitlab.slack.com/app_redirect?channel=fulfillment_monetization_fyi) | Front door for questions to either section |
| [#fulfillment_monetization_design](https://gitlab.slack.com/app_redirect?channel=fulfillment_monetization_design), [#fulfillment_monetization_research](https://gitlab.slack.com/app_redirect?channel=fulfillment_monetization_research) | Product Design and UX Research |
| [#fulfillment_monetization_speak_spark](https://gitlab.slack.com/app_redirect?channel=fulfillment_monetization_speak_spark) | Social |
When asking in the front door channel, react with ✅ once answered. For urgent customer issues use [STAR escalation](/handbook/support/internal-support/support-ticket-attention-requests/). For licensing or subscription requests involving a customer, use the [internal request form](https://support-super-form-gitlab-com-support-support-op-651f22e90ce6d7.gitlab.io/).
We work transparently, keep nearly everything public, and follow the [Product Development Flow](/handbook/product-development/how-we-work/product-development-flow/#workflow-summary).
### SAFE
Our work touches financial and sensitive information. Keep [SAFE](/handbook/legal/safe-framework/) epics, issues, videos, and MRs confidential, and use the [internal handbook](https://internal.gitlab.com/handbook/product/fulfillment/) for anything that cannot be public. See [promising features in future versions](https://docs.gitlab.com/ee/development/documentation/styleguide/availability_details.html#promising-features-in-future-versions).
### Planning
We plan in monthly milestones following the [Product Development Timeline](/handbook/engineering/workflow/#product-development-timeline). Each group has a [planning issue](https://gitlab.com/gitlab-org/fulfillment/meta/-/work_items/?sort=priority_desc&state=opened&label_name%5B%5D=Planning%20Issue&first_page_size=100) that lists prioritized issues and capacity. Around the 26th, PMs and EMs review and weight candidate issues. Scope is final by the 1st.
Engineers work on `Deliverable` issues first, then pick from the top of the remaining milestone issues. Recurring operational work (monitoring rotations, triage) is planned as weighted issues so it counts against capacity.
### Intake request
To request roadmap work, open an [intake issue](https://gitlab.com/gitlab-org/fulfillment/meta/-/work_items/new?type=ISSUE&description_template=intake) and tag a PM. The PM evaluates it, creates an epic on the roadmap, links it from the intake issue, and closes the intake issue. We do not action requests outside this process.
### Prioritization
We follow the [prioritization framework](/handbook/product/product-processes/#prioritization) and [cross-functional prioritization](/handbook/product/product-processes/cross-functional-prioritization/). Inputs include SLAs, OKRs, the [Support priority issues list](/handbook/support/license-and-renewals/workflows/managing_product_issues/#supports-issue-list-for-fulfillment), and technical debt. We use the company 60/40 split between new work and maintenance as a guideline, not a rule. Each group sets its balance in its OKRs, escalating to the section if needed. Every team runs the [monthly prioritization template](https://gitlab.com/gitlab-org/fulfillment-meta/-/blob/master/.gitlab/issue_templates/monthly-prioritization.md) for cross-functional dashboard reviews.
### Estimation
Estimate after a preliminary investigation, usually during planning.
| Weight | Description |
|--------|-------------|
| 1 | Simplest possible change, no side effects. |
| 3 | Simple change with a bigger footprint. Requirements clear. |
| 5 | Complex change across areas, possibly refactoring. Some gaps likely. |
| 8 | Complex change touching much of the codebase or needing lots of input. |
| 13 | Significant change with dependencies and unclear requirements. Break it down before committing. |
We value [velocity over predictability](/handbook/engineering/development/principles/#velocity) but aim for 80% predictability because our work is cross-functional. When unsure, estimate high or split into a [spike](/handbook/product/product-processes/#spikes) and an implementation issue. Revise estimates immediately when they change and tell the PM.
### Weekly async issue updates
Engineers update their assigned issues weekly:
```markdown
### Async issue update
1. Current status (one sentence):
1. Confidence this lands in the milestone: not / slightly / very
1. Can this be broken down further? yes / no
1. Were expectations from the last update met? If not, why:
Larger projects post weekly status in the parent epic covering % complete, status against key dates, risks and blockers with mitigation, and results.
### Demos
Share progress on multi-milestone work through demos in the [Fulfillment Demos playlist](https://www.youtube.com/playlist?list=PL05JrBw4t0KpOKxufy-slaR-6swIfkDLP), following the [demo process](/handbook/engineering/workflow/demos/). Link the epic or MR in the description.
### User experience
Product Designers follow the [Product Design workflows](/handbook/upstream-studios/product-design/workflow/) and are assigned to projects, not groups, reviewed quarterly in the [UX priorities issue](https://gitlab.com/gitlab-org/fulfillment/meta/-/issues/?label_name%5B%5D=Fulfillment%20UX%20Priorities). Medium and large projects use a `[UX]` issue as the SSOT for designs. Request UX help or MR reviews in [#fulfillment_monetization_design](https://gitlab.slack.com/app_redirect?channel=fulfillment_monetization_design).
### Retrospectives
We run a monthly [async retrospective](/handbook/engineering/careers/management/group-retrospectives/) in [gl-retrospectives/fulfillment](https://gitlab.com/gl-retrospectives/fulfillment/issues/) after the 8th, followed by a recorded sync discussion around the 26th on a rotating timezone. Groups may also run quarterly [iteration retrospectives](/handbook/engineering/workflow/iteration/) on a specific issue or epic.
## Onboarding and social
New engineers use the [onboarding template](https://gitlab.com/gitlab-org/fulfillment-meta/-/blob/master/.gitlab/issue_templates/onboarding.md) and get an onboarding buddy. Optional weekly socials and quarterly [team days](https://gitlab.com/gitlab-org/fulfillment-meta/-/issues?sort=created_date&state=all&label_name[]=Team+Day) are on the [shared calendar](https://calendar.google.com/calendar/embed?src=gitlab.com_7199q584haas4tgeuk9qnd48nc%40group.calendar.google.com).
-[Performance indicators](https://internal.gitlab.com/handbook/company/performance-indicators/product/fulfillment-section/) and [engineering dashboards](/handbook/product/groups/product-analysis/engineering/dashboards/)
