To address Melissa's comments - the main reason that this proposal is offered right now is that the Documentation renewal involves a change to a new static site generator, Antora (https://antora.org). Because of this change, the UI for cassandra.apache.org/doc must be rebuilt using the Antora UI (https://gitlab.com/antora/antora-ui-default). If we are rebuilding the UI anyway, why not take the opportunity to update the look and feel of the whole site?
I have pretty much reproduced the current look and feel and built an antora UI bundle, but I'm a copier of design, not a designer. To accomplish a UI that is more modern, like say, https://spark.apache.org or https://ignite.apache.org/, is beyond my expertise. So, an effort to do website UI design would be concurrent with my continued work to improve the content of both the docs pages and the other pages on the Cassandra website. Lorina On Wed, Jul 29, 2020 at 11:34 AM Melissa Logan <loganloganlo...@gmail.com> wrote: > I would offer that design is important, but content matters more -- so > would suggest adding content strategy/development and information > architecture to the checkpoints list. For example, an ecosystem page could > be highly beneficial to end users (what does C* work with?), as well as a > use case/case studies page. > > > On Wed, Jul 29, 2020 at 7:49 AM Mick Semb Wever <m...@apache.org> wrote: > > > We have funds on offer to the project to hire a contractor to update > > the website. > > > > Personally I think this is a fantastic opportunity, it would be great > > to see the website afresh in coordination with the 4.0 release. > > > > With no up-front defining goals or improvements specified, if we go > > forth with the offer, how can we go about optimising such a > > contractor's time? Achieving something we all accept and own can be > > challenging. And I am aware this is a little at odds with how open > > source typically operates, the closest I can think of is code bounties > > which are usually easier to define and spec in advance. In those > > situations the bounty hunter interfaces directly with the community. > > In this situation, we want broader community involvement on something > > as touching as the landing page to the project's website, while > > optimising the contractor's time to their speciality. > > > > If we want to take this on, how can we go about it? > > > > My first suggestion to throw out there, is to tackle it incrementally > > with a few checkpoints along the way: where we can pause and discuss > > and bike-shed all we like without having to involve the contractor's > > time. It’s also worth keeping in mind the ongoing work on converting > > the in-tree docs, its design changes and impact it will have on our > > user base… > > > > Some example of checkpoints are: > > * Various sketches presented and a straw poll from PMC (or the > > broader dev group) (this could also be a 99design contest) > > * Initial prototype of selected sketch > > * Near completion of new website > > * Sign-off of final website (weighted to those actively involved in 2-3) > > > > Do we want to do this? > > Do we think it is feasible? > > Is the above suggestion sound? > > Do we want more/less/different checkpoints? > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
