My Listings dashboard

Tracking your submissions through the review queue, reading reviewer notes, resubmitting after rejection, shipping new versions, deprecating gracefully.

My Listings is your publisher dashboard — every listing you've created, in whatever state. Sign-in required (the marketplace GitHub identity owns the listings; anonymous browsing can't see this page).

What's shown

Each row in your dashboard shows:

  • Title + kind + slug — links to the public listing detail page (or the draft preview, depending on status).
  • Status badge — one of:
StatusMeaning
draftCreated but not yet submitted. Editable. Not visible to anyone else.
pending_reviewSubmitted; in the moderator queue. Editable but every edit re-queues it.
approvedLive in the public catalog. Editable for metadata; payload changes need a new version.
rejectedModerator rejected. Read the notes, edit, resubmit.
deprecatedRetired by you or by an admin. Existing installs keep working; not in search.
  • Reviewer notes — appears under rejected listings. Click to expand the full feedback the moderator left.
  • Counters — download count + review count + average rating.
  • Updated at — last edit or status change.

Actions per status

What you can do depends on the listing's current status:

ActionWhen
Edit metadataAny non-deleted status. Editing a draft keeps it draft; editing an approved updates the public listing's title/summary/readme but payload changes need a new version submission.
Submit for reviewdraft and rejected only. Flips status to pending_review and the listing appears in the operator queue.
Add a new versionapproved (most common) or rejected (less common — usually you fix the rejected version instead). New version goes to pending_review independently of the parent listing's status.
Deprecateapproved only. Hides from search; existing installs keep working.
Delete (soft)draft only. A submitted listing can't be deleted by the publisher; ask an operator to take it down via the takedown flow.

Common flows

After a rejection

  1. Open the rejected listing from My Listings.
  2. Expand the reviewer notes — operators are required to leave a reason on rejection (see the rubric in Reviewing submissions).
  3. Edit the manifest to address the feedback. Validate locally via enclaw-mp validate if you used the CLI.
  4. Submit for review — listing flips back to pending_review and rejoins the operator queue.

There's no limit on resubmissions; the same listing can cycle pending_review → rejected → pending_review indefinitely until both sides agree it's ready.

Shipping a new version

  1. Open an approved listing.
  2. Add new version → fill in the new semver + changelog + payload. Existing approved version stays live for installers while the new one waits in the queue.
  3. When the moderator approves the new version, it becomes the default for new installs. Existing tenants on the old version keep working until they opt in to update — see Updates + uninstall.

Deprecating gracefully

  1. Open the listing → Deprecate.
  2. Listing disappears from the public catalog search; existing installs keep working until they explicitly remove the binding.
  3. Add a deprecation note to the README explaining what to use instead — installers re-visiting the listing detail page will still see it.

You can un-deprecate by editing the listing's status back to approved (only the publisher or an admin can do this; the action is in the listing detail page, not the dashboard).