BREAKING CHANGE: implement docusaurus

[serhanwbahar]

No description provided.

[jakubgs]

Is this ready or still a work-in-porgress?

[jakubgs]

If this is a complere revamp of the site you should have just used a complete new branch.

We are completely removing a license, and not replacing it, is that intentional?

I adjusted the Jenkinsfile a bit. Other than that looks good to me.

[arnetheduck]

what's the background of these changes? A massive "BREAKING CHANGE" without any description wiht 200 changed files is .. hard to review?

[arnetheduck]

from the little information the title gives this should first go onto a staging deployment in a separate branch (no need to wait for a review either, this way)

[jakubgs]

Talk to @amirhouieh about this. Jarrad demanded a revamp of all sites. This is it.

Also, develop branch IS the staging ground which deploys to https://dev.nimbus.team/.
It's the master branch that deploys to https://nimbus.team/.

[arnetheduck]

ok, so the basic things a PR like this should provide is:

• a humane description of the work done, ie background, what changes where done (was it just style? content? rendering engine? what is it?)
• a testing plan, ie how to go from PR to Q/A & review (this PR cannot meaningfully be reviewed in its current shape, its substance needs a different review format than diff)
• a deployment plan, ie how to go from staging to production, who owns this and what the acceptance criteria are
• a rollback plan, ie how and why to roll back, and who is responsible for this
• a maintenance plan, ie who will own the technical solution going forwards - the current site engine was chosen because the current maintainers were comfortable enough dealing with problems that might ensue - who will deal with problems down the line when things break? are there resources to cover this? docosaurus is something of an arbitrary choice here, ie a few months back it was mkdocs and now it's docosaurus - what will it be next week and who will do the work of converting back and forth?

typically, the above points would have been presented / thought about prior to beginning actual work, in the form of issues open in this repo or some other commonly accepted forum where people affected by the changes hang out - maybe this has happened, in which case it should be linked to in the PR so that we have a trail to follow in future upgrades to the site.

[amirhouieh]

@jakubgs thanks for the instructions, definitely helpful and will surely follow for further and upcoming projects.

However as for this particular project at this point of time, to be honest the request came to us as a urgency and within a super short notice with insanely short deadline. This of course effected our standard development pipeline as well as mis-alignments and miscommunications. Particularly in this case me and the team were under impression that all required communications will be handled by other folks in comms hub which apparently didn't happen.

Anyhow as said, lesson learned and lets catch up on this when storm is over. We surely can benefit from a well establish routine between infra team and our development team.

[kdeme]

Had a quick search on anything mentioning "Portal" in the changes. Not planning on reviewing the whole thing as is.

[kdeme]

Wrong name for the link (Waku).

[kdeme]

Trust is only 1 part of the story. The other is, as you mentioned above, that they are centralized entities and thus muc more susceptible to take downs (and perhaps DoS attacks). Portal is about trust + fully decentralized (no server - client model).

[kdeme]

This is currently called the Nimbus Verified Proxy: https://github.com/status-im/nimbus-eth1/tree/master/nimbus_verified_proxy

This type of light clients solves (somewhat) the trust part, however not yet the centralized part.

[kdeme]

Might also want to mentioned something about the consensus light client that we have (and spearheaded)?

[jakubgs]

Should this be closed since the other PR was merged?

• Update Nimbus website (Logos theme) #169