Packaging knowledge
Team standards with workspaces
Define naming, install, uninstall and detection standards once and reuse them across packages.
Why personal standards fail
Every admin has their own pattern: different package name, different detection, different folder structure. Individually that works. As a team it becomes a collection nobody fully understands.
Standards are not formalism. They are what keeps a package maintainable after its author has moved on.
What a workspace fixes
A workspace bundles a team's rules: naming, install and uninstall patterns, detection defaults, templates. New packages start at the convention, not at zero. Changes apply to everyone and are visible.
In PilotDeploy, workspaces, workspace standards and templates are enterprise features.
Approval and change
A standard anyone can change at any time is not a standard. Templates need approval, changes need a trace. Exceptions are documented, not written into the package as silent special cases.
Limits
A workspace does not replace a technical decision. It makes decisions look the same — not correct. A wrong standard only becomes wrong faster with a workspace.
Four steps to introduce it
Collect the current state, define three rules (names, detection, uninstall), build one template from them, apply it to one package. Start with twenty rules and you introduce nothing.
---