Hello Team,

Just food for thought.

I'm not actively contributing to the project at this time, but the subject
matter caught my attention.

Conversations around fonts, and React, etc. Who are you creating docs for?
Who is the target audience?

My two cents is that human readers are declining and LLM Web Scrapers are
exploding. Docs, moving forward, should target the latter.

What do those docs look like? Well, just plain markdown files. What should
the content be? Definitely an overview of the project, detailed discussions
of use cases, a list of best practices (and bad practices), and lots of
solid code examples. But then again, I wouldn't think too hard about it.
Just prompt an LLM "Create docs optimized for LLMs for my project."

David

On Wed, Apr 29, 2026, 1:52 PM Andor Molnár <[email protected]> wrote:

> I restarted the CI on the PR. Let’s see how it goes.
>
> I prefer the 2nd approach, but if we store the stuff on 'asf-site' branch,
> do
> we still need the ‘website’ branch?
>
> Sounds a bit odd at first glance, but if I understand well, previous
> released
> docs (which is a static thing that never changes) could be present on
> `asf-site` only and in the release process we just add new content to it.
>
> Andor
>
>
>
>
> > On Apr 29, 2026, at 06:33, Yurii Palamarchuk <
> [email protected]> wrote:
> >
> > Fixed, now it works. Currently only one test is failing, and it doesn't
> > seem to be related to my changes.
> >
> > The last thing left to think about is how we want to store the released
> > docs. I'm proposing two ways:
> >
> > 1) Just store them in the master branch with the website source code. All
> > released docs take 800 MB of space so far. It's not ideal, but not fatal
> > either. Fetching it just once won't hurt that much. This way the release
> > management is much easier since everything is stored in one repo, in the
> > same branch. To release a new docs version we just store the last build
> > under the "public/released-docs" folder, update the current version and
> > push the change. That's it.
> >
> > 2) Store the released docs in the `asf-site` branch. This branch stores
> the
> > build being served. For example, we already do this for HBase (though
> it's
> > in a separate repo, which isn't the point here), but we don't have that
> > many old versions there. This way we don't store heavy archives in the
> > master branch, but it comes with a tradeoff. In the master branch, we
> have
> > to maintain an array of all released versions, we got more than 50 of
> them.
> > We need to show the list of all previously released docs on the website.
> To
> > release a new version of ZooKeeper we have to open two PRs, one for
> > `master` and another for `asf-site`. The flow is like this: we build
> > `master`, then we store the last build in the `asf-site` branch as other
> > released docs. In `master`, we update the released versions array, and
> the
> > current version. Then push the changes.  Not that big of a deal but we
> have
> > to keep the docs versions in sync between two repos just to avoid
> fetching
> > 800 MB once.
> >
> > Which way looks better to you and why? I'd go with the first, since it's
> > just simpler. Thanks!
> >
> >
> > *Regards,Yurii*
> >
> > On Wed, Apr 29, 2026 at 1:33 AM Christopher <[email protected]> wrote:
> >
> >> The base image is ubuntu, I believe, so you'll just have to add steps
> >> to the GitHub Actions workflows to apt-get install whatever.
> >>
> >> On Fri, Apr 24, 2026 at 3:22 PM Andor Molnár <[email protected]> wrote:
> >>>
> >>> Somewhere here perhaps …
> >>>
> >>> https://github.com/apache/zookeeper/tree/master/.github/workflows
> >>>
> >>> Andor
> >>>
> >>>
> >>>
> >>>> On Apr 24, 2026, at 10:04, Enrico Olivelli <[email protected]>
> >> wrote:
> >>>>
> >>>> Il giorno ven 24 apr 2026 alle ore 16:49 Yurii Palamarchuk <
> >>>> [email protected]> ha scritto:
> >>>>
> >>>>> Hi everyone,
> >>>>>
> >>>>> To run the website tests, we must install the missing dependencies on
> >> the
> >>>>> remote runner. Can anyone help with this?
> >>>>>
> >>>>>
> >>>>>
> >>
> https://github.com/apache/zookeeper/actions/runs/24838423432/job/72730186177?pr=2373#step:5:7082
> >>>>
> >>>>
> >>>>
> >>>> I would say that you have to update the CI job to setup the tools you
> >> need
> >>>>
> >>>> Enrico
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>> Regards,
> >>>>> Yurii
> >>>>>
> >>>>> On Fri, Apr 17, 2026 at 4:27 PM Yurii Palamarchuk <
> >>>>> [email protected]> wrote:
> >>>>>
> >>>>>> Sure. I'm opening a PR now!
> >>>>>>
> >>>>>> On Thu, Apr 16, 2026 at 3:31 PM Andor Molnár <[email protected]>
> >> wrote:
> >>>>>>
> >>>>>>> Thanks David.
> >>>>>>>
> >>>>>>> Totally agree.
> >>>>>>> Can we move on with the new website Yurii?
> >>>>>>> What do you need to open pull request? What are the open questions?
> >>>>>>>
> >>>>>>> Andor
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Apr 16, 2026, at 02:07, Dávid Paksy <[email protected]> wrote:
> >>>>>>>>
> >>>>>>>> Hi All,
> >>>>>>>>
> >>>>>>>> In the meantime the Apache Phoenix team merged the new website,
> you
> >>>>> can
> >>>>>>> see
> >>>>>>>> it here: https://phoenix.apache.org/.
> >>>>>>>>
> >>>>>>>> On the other day I had to wait for an hour and I only had my
> >>>>> smartphone
> >>>>>>> on
> >>>>>>>> me and I was able to read ZooKeeper documentation from the
> >> redesigned
> >>>>>>>> website and learn from it. While not impossible, it would be
> >> harder to
> >>>>>>> do
> >>>>>>>> this with the current documentation pages.
> >>>>>>>>
> >>>>>>>> Regarding security vulnerabilities, actually the current ZooKeeper
> >>>>>>> website
> >>>>>>>> page contains Bootstrap v4.1.3 which is end-of-life and contains
> >> one
> >>>>>>> known
> >>>>>>>> XSS vulnerability and jQuery v3.3.1 which contains 4 known
> security
> >>>>>>>> vulnerabilities, including the critical CVE-2019-11358 (Prototype
> >>>>>>>> Pollution) and multiple Cross-Site Scripting (XSS) issues.
> >>>>>>>>
> >>>>>>>> Personally I'd vote for technical modernization here to fix the
> >>>>> current
> >>>>>>>> CVE-s and because this also makes the documentation more easy to
> >>>>>>> approach.
> >>>>>>>> I can also offer my help in the website dependency updates.
> >>>>>>>>
> >>>>>>>> Best Regards,
> >>>>>>>> Dávid
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Yurii Palamarchuk <[email protected]> ezt írta
> >> (időpont:
> >>>>>>> 2026.
> >>>>>>>> ápr. 2., Cs, 10:48):
> >>>>>>>>
> >>>>>>>>> Here is the code:
> >>>>>>>>>
> >>>>>>>>> https://github.com/yuriipalam/zookeeper-website
> >>>>>>>>>
> >>>>>>>>> It's not a PR for the zookeeper repo yet.
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>> Yurii
> >>>>>>>>>
> >>>>>>>>> On Thu, Apr 2, 2026 at 3:33 AM Christopher <[email protected]>
> >>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Where is the code for the react version of the site?
> >>>>>>>>>>
> >>>>>>>>>> On Wed, Apr 1, 2026 at 2:53 AM Dávid Paksy <
> [email protected]
> >>>
> >>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Hi All,
> >>>>>>>>>>>
> >>>>>>>>>>> To have a sense about maintenance need, you can see the
> >> JavaScript
> >>>>>>>>>>> dependabot PR-s in the HBase repo here:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>
> https://github.com/apache/hbase/pulls?q=is%3Apr+author%3Aapp%2Fdependabot+is%3Aclosed+label%3Ajavascript
> >>>>>>>>>>>
> >>>>>>>>>>> So yes, it requires some maintenance.
> >>>>>>>>>>> I'd also recommend to enable Dependabot dependency updates as
> >> they
> >>>>>>> are
> >>>>>>>>>>> helpful. But if not, running 'npm audit fix' manually is rather
> >>>>> easy.
> >>>>>>>>>>>
> >>>>>>>>>>> For how the sources look you can check here what Yuri
> >> implemented
> >>>>> for
> >>>>>>>>>> HBase:
> >>>>>>>>>>>
> >>>>>>>>>>> https://github.com/apache/hbase/tree/master/hbase-website
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Best regards,
> >>>>>>>>>>> Dávid
> >>>>>>>>>>>
> >>>>>>>>>>> Christopher <[email protected]> ezt írta (időpont: 2026.
> >> márc.
> >>>>>>> 31.,
> >>>>>>>>> Ke
> >>>>>>>>>>> 22:47):
> >>>>>>>>>>>
> >>>>>>>>>>>> It's also pretty easy to use dependabot on the website repo to
> >>>>> check
> >>>>>>>>>>>> for updated site dependencies. That should be easy to handle
> if
> >>>>> the
> >>>>>>>>>>>> assets are included in the repo itself, and not loaded from
> >> other
> >>>>>>>>>>>> domains, as per the ASF policy
> >>>>>>>>>>>> (https://privacy.apache.org/policies/website-policy.html)
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Tue, Mar 31, 2026 at 11:05 AM Yurii Palamarchuk
> >>>>>>>>>>>> <[email protected]> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I know about it, and we're not affected by it. This
> >> vulnerability
> >>>>>>>>>> allows
> >>>>>>>>>>>>> attackers to bypass the React's server authentication, but we
> >>>>> don't
> >>>>>>>>>> use
> >>>>>>>>>>>> it.
> >>>>>>>>>>>>> We don't have any runtime node.js server, so we aren't
> >> affected
> >>>>> by
> >>>>>>>>>> any of
> >>>>>>>>>>>>> these.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Best Regards,
> >>>>>>>>>>>>> Yurii
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Tue, Mar 31, 2026 at 4:38 PM Patrick Hunt <
> >> [email protected]>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> this is from december :-)
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >> https://www.wiz.io/blog/critical-vulnerability-in-react-cve-2025-55182
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Patrick
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Tue, Mar 31, 2026 at 7:27 AM Yurii Palamarchuk <
> >>>>>>>>>>>>>> [email protected]> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> You are right, there are almost no concerns. The entire
> >> website
> >>>>>>>>>> is
> >>>>>>>>>>>>>> static,
> >>>>>>>>>>>>>>> only the server providing the assets is running. The only
> >> issue
> >>>>>>>>>>>> could be
> >>>>>>>>>>>>>> if
> >>>>>>>>>>>>>>> some node.js package becomes vulnerable, allowing hackers
> to
> >>>>>>>>> run
> >>>>>>>>>>>> scripts
> >>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>> users' machines, but this scenario is highly unlikely.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Best Regards,
> >>>>>>>>>>>>>>> Yurii
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Tue, Mar 31, 2026 at 4:22 PM Patrick Hunt <
> >> [email protected]
> >>>>>>>>>>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> What are the security implications of running React on the
> >> ZK
> >>>>>>>>>>>> website?
> >>>>>>>>>>>>>> Is
> >>>>>>>>>>>>>>>> that going to mean additional concerns (eg cve tracking as
> >>>>>>>>>> well as
> >>>>>>>>>>>>>> source
> >>>>>>>>>>>>>>>> security bugs, tracking the "latest react" version and so
> >>>>>>>>>> on...). I
> >>>>>>>>>>>>>>>> believe right now we just have very simple static pages
> >> which
> >>>>>>>>>>>> require
> >>>>>>>>>>>>>>> very
> >>>>>>>>>>>>>>>> minimal oversight?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Patrick
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Tue, Mar 31, 2026 at 7:17 AM Yurii Palamarchuk <
> >>>>>>>>>>>>>>>> [email protected]> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Thanks everyone for your reviews!
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> The only approach I considered for updating the
> >>>>>>>>> documentation
> >>>>>>>>>>>> version
> >>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>> manual one. It looks like this:
> >>>>>>>>>>>>>>>>> 1) Checkout to the `website` branch.
> >>>>>>>>>>>>>>>>> 2) Build the latest change for the current version, right
> >>>>>>>>>> before
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> update.
> >>>>>>>>>>>>>>>>> 3) Move the build to `public/released-docs/` and rename
> >> the
> >>>>>>>>>>>> directory
> >>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>> the corresponding version.
> >>>>>>>>>>>>>>>>> 4) Update the `CURRENT_VERSION` constant, so now it
> >> matches
> >>>>>>>>>> the
> >>>>>>>>>>>> new
> >>>>>>>>>>>>>>>>> version.
> >>>>>>>>>>>>>>>>> 5) Open a PR.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> The Java API docs are built by maven as far as I can
> tell,
> >>>>>>>>> so
> >>>>>>>>>>>> it's
> >>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>> related to the website actually.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Regarding the automatization of this process, I've never
> >>>>>>>>> done
> >>>>>>>>>>>>>> anything
> >>>>>>>>>>>>>>>> like
> >>>>>>>>>>>>>>>>> this before. Therefore, if you have any suggestions - I'm
> >>>>>>>>>> open to
> >>>>>>>>>>>>>> it, I
> >>>>>>>>>>>>>>>>> think it should be possible since the workflow is not
> >>>>>>>>>> complex at
> >>>>>>>>>>>> all.
> >>>>>>>>>>>>>>>> Most
> >>>>>>>>>>>>>>>>> likely a small bash script could be enough.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Best Regards,
> >>>>>>>>>>>>>>>>> Yurii
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Tue, Mar 31, 2026 at 3:09 AM Andor Molnár <
> >>>>>>>>>> [email protected]>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Exactly. My 2 cents are:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 1. Storing the entire website at a single location is
> >>>>>>>>>>>> desirable.
> >>>>>>>>>>>>>>> Given
> >>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>> proposed
> >>>>>>>>>>>>>>>>>> technology changes there’s no clear separation possible
> >>>>>>>>>> without
> >>>>>>>>>>>>>>>>> duplicating
> >>>>>>>>>>>>>>>>>> website core logic components which will be a
> maintenance
> >>>>>>>>>>>> nightmare
> >>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>> long term.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 2. Separate ‘website’ branch or versioned branches. As
> >>>>>>>>>> Patrick
> >>>>>>>>>>>>>>>> mentioned
> >>>>>>>>>>>>>>>>>> the docs are versioned and the ability to accompany doc
> >>>>>>>>>> changes
> >>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>> code changes in the same PR is a big advantage.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Andor
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Mar 30, 2026, at 19:52, Patrick Hunt <
> >>>>>>>>>> [email protected]>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> One reason I remember the docs/api/etc... are part of
> >>>>>>>>> the
> >>>>>>>>>>>> source
> >>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>> they are versioned along with it. PRs -- doc changes
> >>>>>>>>>> along
> >>>>>>>>>>>> with
> >>>>>>>>>>>>>>> code
> >>>>>>>>>>>>>>>>>>> changes also part of the release process.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Patrick
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Mon, Mar 30, 2026 at 5:39 PM Christopher <
> >>>>>>>>>>>> [email protected]
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I think it looks great, but I would really like to see
> >>>>>>>>>> the
> >>>>>>>>>>>> SCM
> >>>>>>>>>>>>>>>> source
> >>>>>>>>>>>>>>>>>>>> for this new site, so I can understand the
> >>>>>>>>>> maintenance/build
> >>>>>>>>>>>>>>>> workflow
> >>>>>>>>>>>>>>>>>>>> for it, before I'd have any useful opinion other than
> >>>>>>>>>>>> regarding
> >>>>>>>>>>>>>>>>>>>> aesthetics.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I definitely concur with moving the docs out to the
> >>>>>>>>>> site to
> >>>>>>>>>>>>>>>> centralize
> >>>>>>>>>>>>>>>>>> it.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On Fri, Mar 27, 2026 at 3:03 PM Yurii Palamarchuk
> >>>>>>>>>>>>>>>>>>>> <[email protected]> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Thanks for your comment, Patrick.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Why React?
> >>>>>>>>>>>>>>>>>>>>> Building a website nowadays is not just HTML + CSS,
> >>>>>>>>>> because
> >>>>>>>>>>>>>> doing
> >>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>>>>>> way turns the developer experience into a nightmare.
> >>>>>>>>>> With
> >>>>>>>>>>>> React
> >>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>> effortlessly have consistent UI components across all
> >>>>>>>>>>>> pages,
> >>>>>>>>>>>>>>>>> including
> >>>>>>>>>>>>>>>>>>>>> buttons, tables, markdown rendering, colors, and much
> >>>>>>>>>>>> more. We
> >>>>>>>>>>>>>>> also
> >>>>>>>>>>>>>>>>> add
> >>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>> interactivity much more easily with React. A static
> >>>>>>>>>> website
> >>>>>>>>>>>>>>> doesn't
> >>>>>>>>>>>>>>>>>> mean
> >>>>>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>>> lacks interactivity; it often has significant
> >>>>>>>>>>>> interactivity,
> >>>>>>>>>>>>>>>>> especially
> >>>>>>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>>> the documentation section. The difference is that we
> >>>>>>>>>> don't
> >>>>>>>>>>>> need
> >>>>>>>>>>>>>>> any
> >>>>>>>>>>>>>>>>>>>> runtime
> >>>>>>>>>>>>>>>>>>>>> environment, we just return the files generated at
> >>>>>>>>>> build
> >>>>>>>>>>>> time,
> >>>>>>>>>>>>>>>> which
> >>>>>>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>>>> ultimately just HTML, CSS, and JS. The website also
> >>>>>>>>> has
> >>>>>>>>>>>> dark
> >>>>>>>>>>>>>> mode
> >>>>>>>>>>>>>>>>>>>> support,
> >>>>>>>>>>>>>>>>>>>>> search in the documentation, smooth transitions
> >>>>>>>>> between
> >>>>>>>>>>>> pages
> >>>>>>>>>>>>>> (no
> >>>>>>>>>>>>>>>>> hard
> >>>>>>>>>>>>>>>>>>>>> reload), so it gives smooth and better user
> >>>>>>>>> experience
> >>>>>>>>>>>>>> overall. I
> >>>>>>>>>>>>>>>>> hope
> >>>>>>>>>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>>>>>> answers your question. Moreover, the website will
> >>>>>>>>> work
> >>>>>>>>>>>>>> absolutely
> >>>>>>>>>>>>>>>>> fine
> >>>>>>>>>>>>>>>>>>>> even
> >>>>>>>>>>>>>>>>>>>>> for those who have JS disabled, this is called
> >>>>>>>>>> progressive
> >>>>>>>>>>>>>>>>> enhancement.
> >>>>>>>>>>>>>>>>>>>>> Initially, the server returns HTML and CSS. The
> >>>>>>>>> browser
> >>>>>>>>>>>> renders
> >>>>>>>>>>>>>>>> them
> >>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>> tries to fetch the JS files. If it doesn't succeed,
> >>>>>>>>> the
> >>>>>>>>>>>> page
> >>>>>>>>>>>>>>>> remains
> >>>>>>>>>>>>>>>>>>>>> accessible, though it obviously lacks interactivity.
> >>>>>>>>> I
> >>>>>>>>>> hope
> >>>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>>> answers
> >>>>>>>>>>>>>>>>>>>>> your questions, if not, feel free to ask more about
> >>>>>>>>> it!
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Is it hard for ZK devs to update the content?
> >>>>>>>>>>>>>>>>>>>>> Not at all! I tried to make it so the learning curve
> >>>>>>>>>> for
> >>>>>>>>>>>> non-JS
> >>>>>>>>>>>>>>>> devs
> >>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>> almost 0. For the documentation you still just need
> >>>>>>>>> to
> >>>>>>>>>>>> edit the
> >>>>>>>>>>>>>>> MDX
> >>>>>>>>>>>>>>>>>>>>> (Markdown Extended) files and run the build command.
> >>>>>>>>> I
> >>>>>>>>>> will
> >>>>>>>>>>>>>> also
> >>>>>>>>>>>>>>>> add
> >>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>> bash
> >>>>>>>>>>>>>>>>>>>>> script to automate the build process. For the landing
> >>>>>>>>>>>> pages,
> >>>>>>>>>>>>>> you
> >>>>>>>>>>>>>>>>> still
> >>>>>>>>>>>>>>>>>>>>> mostly only need to modify the markdown files. Only
> >>>>>>>>> the
> >>>>>>>>>>>> main
> >>>>>>>>>>>>>> page
> >>>>>>>>>>>>>>>>> isn't
> >>>>>>>>>>>>>>>>>>>>> markdown, modifying something small wouldn't be a
> >>>>>>>>>> problem.
> >>>>>>>>>>>> In
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> worst
> >>>>>>>>>>>>>>>>>>>>> case, if something more complex is required, you can
> >>>>>>>>>>>> handle it
> >>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> AI.
> >>>>>>>>>>>>>>>>>>>>> Nevertheless, the website hasn't been updated for
> >>>>>>>>>> years,
> >>>>>>>>>>>> so it
> >>>>>>>>>>>>>>>>> wouldn't
> >>>>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>> a big loss :)
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>>>>>>>>>> Yurii
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Fri, Mar 27, 2026 at 4:19 PM Patrick Hunt <
> >>>>>>>>>>>> [email protected]
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> On Fri, Mar 27, 2026 at 3:32 AM Yurii Palamarchuk <
> >>>>>>>>>>>>>>>>>>>>>> [email protected]> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Hi there,
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I am proposing an upgrade to the ZooKeeper website
> >>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>> documentation. We
> >>>>>>>>>>>>>>>>>>>>>>> are moving to a modern React.js stack, which allows
> >>>>>>>>>>>> landing
> >>>>>>>>>>>>>>> pages
> >>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>> versioned documentation to live in a single
> >>>>>>>>>> application
> >>>>>>>>>>>>>> sharing
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> same
> >>>>>>>>>>>>>>>>>>>>>> UI
> >>>>>>>>>>>>>>>>>>>>>>> components, libraries, colors, etc.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> The plan is to move all website and documentation
> >>>>>>>>>> source
> >>>>>>>>>>>> code
> >>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> website branch and remove the zookeeper-docs Maven
> >>>>>>>>>>>> project
> >>>>>>>>>>>>>> from
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>> master
> >>>>>>>>>>>>>>>>>>>>>>> branch. This decouples the Node/JS build
> >>>>>>>>> environment
> >>>>>>>>>>>> from the
> >>>>>>>>>>>>>>>> core
> >>>>>>>>>>>>>>>>>>>> Java
> >>>>>>>>>>>>>>>>>>>>>>> repository.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Versioned docs will be managed via archived folders
> >>>>>>>>>>>> within
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> website
> >>>>>>>>>>>>>>>>>>>>>>> branch. Documentation updates would move from
> >>>>>>>>> master
> >>>>>>>>>> to
> >>>>>>>>>>>> PRs
> >>>>>>>>>>>>>>>> against
> >>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> website branch. Also I'm not planning to keep the
> >>>>>>>>>> app as
> >>>>>>>>>>>> a
> >>>>>>>>>>>>>>> maven
> >>>>>>>>>>>>>>>>>>>> project,
> >>>>>>>>>>>>>>>>>>>>>>> since it's fully JS based. To keep it simple, I
> >>>>>>>>> will
> >>>>>>>>>>>> write a
> >>>>>>>>>>>>>>> bash
> >>>>>>>>>>>>>>>>>>>> script
> >>>>>>>>>>>>>>>>>>>>>>> that installs the dependencies, runs the tests, and
> >>>>>>>>>> the
> >>>>>>>>>>>>>> build.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> What do you think about moving the docs out of
> >>>>>>>>>> master to
> >>>>>>>>>>>>>>>> centralize
> >>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> site?
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Preview: https://zookeeper-website.vercel.app/
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Looks pretty slick - nice update and visual refresh!
> >>>>>>>>>>>> Question
> >>>>>>>>>>>>>>>>> though -
> >>>>>>>>>>>>>>>>>>>> why
> >>>>>>>>>>>>>>>>>>>>>> React? This is a static website, what are the
> >>>>>>>>> pro/con
> >>>>>>>>>> of
> >>>>>>>>>>>> React
> >>>>>>>>>>>>>>>>> based?
> >>>>>>>>>>>>>>>>>>>> Can
> >>>>>>>>>>>>>>>>>>>>>> you explain the impact on common use cases like
> >>>>>>>>> making
> >>>>>>>>>>>>>> updates?
> >>>>>>>>>>>>>>> ZK
> >>>>>>>>>>>>>>>>>> team
> >>>>>>>>>>>>>>>>>>>>>> includes a number of people, not all of whom might
> >>>>>>>>>> know
> >>>>>>>>>>>> React,
> >>>>>>>>>>>>>>> how
> >>>>>>>>>>>>>>>>>> hard
> >>>>>>>>>>>>>>>>>>>>>> will it be for them to make changes? Impact on the
> >>>>>>>>>> release
> >>>>>>>>>>>>>>>> process?
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Patrick
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>>>>>>>>>>>> Yurii Palamarchuk
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >>
>
>

Reply via email to