Re: User-facing website vs. contributor-facing website

AFAIR, the main point to use Wiki last time was a lower entry bar, comparing to the main website, for everybody to add a new information related to any of aspects of Beam. On the flip side, as it was mentioned above, this information is mostly not reviewed, bad structured and not easy to find i

Re: User-facing website vs. contributor-facing website

On Fri, Sep 22, 2023 at 8:05 AM Danny McCormick via dev wrote: > > I do feel strongly that https://beam.apache.org/contribute/ should > remain on the main site, as it's aimed at users (who hopefully want to step > up and contribute) > > To be clear, I don't think anyone is suggesting getting rid

Re: User-facing website vs. contributor-facing website

> I do feel strongly that https://beam.apache.org/contribute/ should remain on the main site, as it's aimed at users (who hopefully want to step up and contribute) To be clear, I don't think anyone is suggesting getting rid of the section, my comments were about replacing the side panel links with

Re: User-facing website vs. contributor-facing website

I feel like that's actually pretty easy with Github actions? I think maybe there's even one that exists Github Pages and probably any other static site generator thingy we could care to name. Related, I stumbled across this the other day: https://github.com/apache/beam-site which appears to be unus

Re: User-facing website vs. contributor-facing website

TBH, I'm not a huge fan of the wikis either. My ideal flow would be something like g3doc, and markdown files in github do a reasonable enough job emulating that. (I don't think the overhead of having to do a PR for small edits like typos is oneros, as those are super easy reviews to do as well...)

Re: User-facing website vs. contributor-facing website

On Thu, Sep 21, 2023 at 3:55 PM Danny McCormick wrote: > > - reviewed > > Generally, I'm actually probably -0 on this one - it depends on context, > but things that are for other developers only are usually better off > without this requirement IMO since you get more contributions and more > use

Re: User-facing website vs. contributor-facing website

> - reviewed Generally, I'm actually probably -0 on this one - it depends on context, but things that are for other developers only are usually better off without this requirement IMO since you get more contributions and more useful/unpolished things. Unfortunately, I'm not sure if confluence act

Re: User-facing website vs. contributor-facing website

OK so this did turn into a discussion all about the tech/hosting :-). It has been 5 years and we have experience of the wiki now so maybe that is fair anyhow. And perhaps the preference of where to put information cannot be separated from it. Top posting because there was so much in common across

Re: User-facing website vs. contributor-facing website

> I might be wrong but I think of wiki as a more volatile and a less reliable place than the Website I agree, the counterpoint is that docs that require more work to update are more likely to go stale since there is higher friction to update. There's also more of an expectation that everything is

Re: User-facing website vs. contributor-facing website

TBH i find the wiki to be entirely unfriendly. It hard to find things in it and isn't discoverable. The syntax is archaic and the UI is wonky. There's no "flow" to it. No common entry point etc. I'd rather the release guide remain in Github as markdown, even if it's not on the website anymore. Th

Re: User-facing website vs. contributor-facing website

I might be wrong but I think of wiki as a more volatile and a less reliable place than the Website (can be updated without a review by any committer and we do that quite often). I think things in the contribution guide are key to a healthy Beam community so I'd like them to be in a more stable plac

Re: User-facing website vs. contributor-facing website

+1 on moving the release guide. I'd argue that everything under the `contribute` tag other than the main page ( https://beam.apache.org/contribute/) and the link to CONTRIBUTING.md makes more sense on the wiki (we can keep the section wit