Hi all,

Just boosting this as some might have missed it in the flood of JIRA mails.

cheers,
  Serge...

On Sun, Jun 21, 2026 at 8:31 PM Serge Huber <[email protected]> wrote:
>
> Hi everyone,
>
> We don’t really have a blog on the Unomi website today. The homepage
> “news” bit is hand-edited HTML, and anything longer usually ends up
> somewhere else — Medium, YouTube, conference sites — with a link from
> Resources.
>
> I’d like to fix that in a simple way: a /blog/ on unomi.apache.org,
> using Jekyll _posts like the rest of the site. Each post would be a
> Markdown file in unomi-site, submitted as a PR on asf-site. Same
> process we already use for website changes.
>
> What I have in mind:
> - Updates on ongoing work — especially 3.x, what’s in progress, what
> we’d like people to try or review
> - Releases explained in normal language (not just a JIRA link)
> - Short write-ups after talks and meetups
> - Posts inspired by our monthly meetings — not minutes copied over,
> but when something interesting comes up on a call, a longer piece for
> people who weren’t there: what we’re talking about, why it matters,
> what the options look like right now. Full discussion stays on dev@.
> - Occasional interviews with Unomi users — a technical Q&A about how
> they use the project in practice. Not a slot for vendor product
> launches.
> - Community posts: tutorials, integration stories, that kind of thing
>
> I’ll try to write regularly myself so the blog doesn’t go stale.
>
> What I’d rather avoid:
>
> - Commercial product announcements and marketing dressed up as blog
> posts. If a company ships something built on Unomi, great — they
> announce it on their side; we can point to it briefly if it’s
> relevant. The blog should stay about Apache Unomi. Ecosystem listings
> stay on Integrations, with the disclaimer we already have there.
>
> How we decide things:
>
> I’d propose lazy consensus in two places, so we’re not blocked waiting
> for specific people to be around:
>
> - This email — if nobody objects within 72 hours (by <date>), I’ll
> open a JIRA ticket (website component) and send a first PR with the
> basic blog setup.
> - Each blog PR — discuss on the PR if needed; if there’s no
> substantive objection after about 72 hours, a committer merges with
> @asfgit merge, like any other site change.
>
> If something’s off — tone, accuracy, vendor neutrality — say so on the
> list or on the PR. That’s the safety net.
>
> If this sounds fine, I’ll get moving. If you think it’s a bad idea, or
> you’re uneasy about meeting topics or user interviews going public,
> please speak up now.
>
> cheers,
>   Serge Huber

Reply via email to