Org sign-off: bbl-dres #8
Labels
No labels
approve
approved
declined
org-signoff
resolved
size-signoff
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
meta/reports#8
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The sources list
bbl-dres, but there is no such organisation on this instance and the scheduled run does not create one unattended — admitting an organisation authorises the import of everything under it, so a person decides. Nothing frombbl-dresis mirrored until it exists.What admitting it costs
Creating the organisation is the whole decision for the 18 repositories below the size cap: the next run imports them with no further review. Anything above the cap is held separately — size is its second blocker, not its first, which is why those have no ticket of their own while this one is open.
The over-cap ones are a second decision, taken later: each gets its own sign-off ticket on the run after this one is admitted, and the same
approvelabel answers it there. Admitting the organisation here does not approve them, and nothing is lost by waiting — they stay listed below and in every run report meanwhile.Above the size cap — need approving too
https://github.com/bbl-dres/data-catalog— 100 MBBelow the cap — imported on admission
https://github.com/bbl-dres/kennwerte-db— 2233 MBhttps://github.com/bbl-dres/reconstruction— 452 MBhttps://github.com/bbl-dres/service-portal— 292 MBhttps://github.com/bbl-dres/tenant-portal— 119 MBhttps://github.com/bbl-dres/process-hub— 33 MBhttps://github.com/bbl-dres/workspace-management— 26 MBhttps://github.com/bbl-dres/plan-check— 21 MBhttps://github.com/bbl-dres/green-inventory— 18 MBhttps://github.com/bbl-dres/ppm-cockpit— 12 MBhttps://github.com/bbl-dres/property-inventory— 12 MBhttps://github.com/bbl-dres/ict-portfolio— 10 MBhttps://github.com/bbl-dres/geo-check— 10 MBhttps://github.com/bbl-dres/area-estimator— 8 MBhttps://github.com/bbl-dres/landcover-survey— 7 MBhttps://github.com/bbl-dres/resource— 7 MBhttps://github.com/bbl-dres/transaction-portal— 5 MBhttps://github.com/bbl-dres/.github— 0 MBhttps://github.com/bbl-dres/mieterportal— 0 MBThree ways to resolve this, all done on this ticket
Admit it — apply the
approvelabel. The next scheduled run recordsbbl-dresinconfig/org_approvals.txt, creates the organisation, imports what is listed above as under-cap, and closes this ticket asapproved.Decline it — close this ticket. The next run records that in
config/org_declines.txtpointing back here and relabels itdeclined; the alert stops namingbbl-dresand the closed ticket becomes the answer for anyone who asks later. Leave a comment saying why before you close — the file links here, so this ticket is where the reason has to live. Reopening it withdraws the line and brings the question back.Leave it — it stays listed in every run report and is not mailed again. That is a decision nobody can read, which is what a recorded decline avoids.
Both of the first two are carried out by the scheduled run, not at the moment you click. Until it next runs, the label or the closure is a request on record and nothing has happened yet.
This ticket's title is how the scheduled job finds it — please do not edit it.
Closing: approved —
bbl-dreswas created on 2026-09-15, and its repositories import on the next run.The decision itself lives in versioned config; this ticket only recorded it.