Requests & Violations

Publishing to the public board

Some requests deserve community visibility — completed maintenance, ARC approvals, enforcement updates. Here's when to publish, how to publish, and what residents see.

Last updated April 29, 2026

By default, requests are private — visible only to the filer, the accused, and the board. But sometimes the community at large benefits from knowing what’s happening. Maintenance was completed. An ARC request was approved. A repeated complaint type was addressed. Publishing makes these visible on the public board that all residents see.

What “publishing” means

When you publish a request:

  • A published version of the request appears on the community board (visible in residents’ portals)
  • The original request thread remains private (you don’t expose internal discussion)
  • You control the published title and description — these are what residents see, not the raw filing
  • Other residents can comment on or react to the publication, depending on your settings

Important: publishing is separate from resolving. You can publish a resolution (informational), but the underlying request and its private discussion stay private.

When to publish

The judgment-call situations where publishing helps:

Maintenance updates that affect everyone

Publish: “The streetlight at the corner of Maple and Oak has been repaired.”

Why: residents stop filing duplicate requests. They see the issue is being handled.

ARC approvals (when the work is visible)

Publish: “The Smiths’ fence project at 123 Maple has been approved by the Architectural Committee. Construction begins May 1.”

Why: heads off neighbor complaints during construction. Sets community expectations.

Resolved enforcement (when relevant for transparency)

Publish: “Reminder: trash cans must be off the curb by 8pm Tuesday. Repeated violations have been addressed this month.”

Why: signals consistent enforcement without naming names. Residents see the board acting.

General-interest answers

Publish: “Q: When can pool guests visit? A: Up to 4 guests per household, no overnight stays. See [Bylaw Section 3.2].”

Why: turns one resident’s question into community-wide reference.

When NOT to publish

The common mistakes:

Don’t publish complaints about identifiable residents

Even if the complaint is valid, publishing names a neighbor. It humiliates them and breaks community trust. Handle complaints privately.

Don’t publish individual disputes

If two residents are in a property-line argument, that’s not the community’s business. Mediate privately.

Don’t publish ARC denials publicly

Approval = public benefit. Denial = private business. Publishing a denial publicly embarrasses the resident and discourages others from filing.

Don’t publish anything you wouldn’t say at an annual meeting

The published board is searchable, persistent, and visible to anyone in the community. Treat it like the bulletin board at the clubhouse — anything you’d hesitate to put up there shouldn’t go up here.

How to publish

  1. Open the request
  2. Click Publish to community
  3. Fill in the public-facing fields:
    • Public title — short, neutral. e.g. “Streetlight repair complete”
    • Public description — what you want residents to know
    • Pinned? — if checked, sticks to the top of the board for emphasis
  4. Confirm

The published version appears on the community board immediately. The original request thread stays private.

Editing or unpublishing

If you need to update or remove a publication:

  • Edit — open the request, click Edit publication, update title/description, save. The change is visible to residents on next page load.
  • Unpublish — open the request, click Unpublish. The publication is hidden from the community board (the original request remains intact).

You can unpublish without affecting the underlying request status. So a resolved request can be unpublished without re-opening it.

What residents see

The community board view shows:

  • The publication’s title (large)
  • Description (paragraph)
  • Date posted
  • Posted by [board member name + title] — e.g., “Posted by Sarah Chen, Treasurer”
  • Comments section (configurable on/off)
  • Pinned indicator if applicable

Residents can:

  • Read all publications
  • Comment if you’ve enabled it
  • React (thumbs up, etc., if enabled)

Residents cannot see:

  • The original request that triggered the publication
  • The internal board discussion
  • Who filed the original complaint

Pinning publications

Use pin sparingly. Pinned items stick to the top of the board indefinitely until you unpin. Good uses:

  • Active community-wide event (“Pool closes for repair April 22-25”)
  • Important policy reminder (“New parking enforcement starts May 1”)
  • Board contact info

Bad uses:

  • Routine resolutions (“Streetlight fixed” doesn’t need pinning)
  • Items more than a couple weeks old
  • More than 2-3 things at once (too many pins = nothing is pinned)

Unpin once the issue is resolved or the date passes.

Comments on publications

Whether residents can comment is configurable per publication. Default is on for general updates, off for sensitive topics.

When comments are on:

  • Any resident can comment
  • All residents see the comments
  • Board can moderate (delete, hide)
  • Threaded replies are supported

Some communities turn comments off entirely (treat the board as one-way announcements). Others love the engagement. Your call.

Publishing frequency

A practical rhythm: 3-5 publications per month for most communities. Less than that and the board feels invisible. More than that and residents stop reading.

Most-published types (in order):

  1. Maintenance status updates (most frequent)
  2. Community-wide reminders / policies
  3. ARC approvals for visible projects
  4. Board meeting recaps
  5. Event announcements (separate from the announcements feature, which is for transient broadcasts)

Common situations

”I published something and a resident is offended”

If the publication identified them or made them feel publicly shamed, unpublish immediately. Apologize privately. Update your publishing guidelines so it doesn’t happen again.

”Should we publish dues collection rates / financial summaries?”

Some communities do, in aggregate (“This quarter, 94% of dues were collected on time. Thanks to all who paid promptly!”). Don’t ever publish per-property balances or non-payers’ names.

”Residents keep asking for status on a published item”

Add an update to the publication. “Update April 22: Streetlight contractor confirmed for May 5.” Residents see the update; the publication stays in place.

”Can residents publish to the board too?”

Not directly. Residents file requests, the board chooses what to publish. This keeps the board the editorial filter.

If your community wants resident-driven publishing (like a community forum), that’s a different feature — not currently part of HomeHerald’s publishing flow.

Where to go next