Wiki-Ops

[salmad3]

Workflows

• Enhance jobs and configuration files
  • build and deploy.
  • Substrate version check: Substrate version check does not seem to be updating the links #1815 Resolved in: update all rustdoc links to point to latest version #2330
  • jobs should be swift and concise where they can be.
• Fix CI/CD substrate rustdoc link updater
  • master CICD should only fail if there is a build error
• Clean-up previous CircleCI implementation
• Stage non-prod versions off of main branch.
• [x] Fix Prettier
• [ ] Run Prettier on external PRs: Make the prettier bot work on external PRs #944 Using pretty-quick instead
• [ ] Abstract stalecheck: Abstract away the stale-check Github Action so others can use it #1064
  • should also have a stale checker for older issues along with current stale checker for docs, and check for duplicate issues before creating an issue. -> instead of this updating in this manner, issues can be managed using a kanban board (ZenHub has been setup, can add with https://www.zenhub.com/extension).
• updating the wiki results in all wiki pages mentioning the individual that committed recently - should only be those pages that were updated: "Last updated on X by Y" is connected to any change on the wiki overall, not the page in question #2452

Version 2

• Fix link issue: links are incorrect after refresh page #2250
  team attempts thus far:
  • play around with config.
  • disable crowdin: Disable Crowdin again #2221
  • disable trailing slash: Disable trailing slash #2281
  • referencing update for possible docusaurus compatibility: Update all Wiki links for v2 compatibility  #2278
• Naming convention
• Injections: Fix Injections  #2443
• Conversion tool: Address conversion tool is not working #2415
  • configuration & reformatting?

Suggestions

• Create sub-directories for "docs" instead of having all wiki pages under one directory. (i.e. learn has learn guides, build has build guides, etc.)
• Need to clean up repo in general - docker related files, configuration files, duplicates, etc.
• [ ] Doc images could use a name convention and also organized into better sub-directories. I would say this can be revisited, but perhaps not a priority atm.
• Update README
• Community engagement and new members would benefit from "good first issues" (a label), such as: Update Glossary Terms  #2298.

Feel free to add/edit/refute and discuss these points.

[nam-hle]

I know it's quite early but removing the old website and kusama-guide folders could be added.
Also, update README.md.

[jakehemmerle]

Readme says master is also pushed to IPFS by github actions but this doesn't seem correct. Should we add a new action to push new masters to IPFS?

[salmad3]

There's no CircleCI workflows that still run behind the scenes, right?

[salmad3]

Whenever anyone gets the chance, can you double check if the links are okay now? I have noticed one thing - when I first access the wiki (any page that is), for a split second it hits "page not found" but redirects.

This also happens until refreshing a few times:

[jakehemmerle]

There's no CircleCI workflows that still run behind the scenes, right?

don't think so (no .circleci folder), also couldn't find a login for it.

[salmad3]

Readme says master is also pushed to IPFS by github actions but this doesn't seem correct. Should we add a new action to push new masters to IPFS?

@jakehemmerle #696

[salmad3]

Brief update:

• cleaned up branches
• there is a branch called v1 that would hold version 1 (& arguably a snapshot of version 2)
• another branch called wikiops that attempts to address... wikiops:) (merges to master)
• another branch could then serve as a dev or test for staging

[jakehemmerle]

• there is a branch called v1 that would hold version 1 (& arguably a snapshot of version 2)

I don't think there is any benefit of sustaining v1 as a separate branch as it just overcomplicates every docs/ edit we make (since we have to open 2 prs; one to merge to v1 and one for v2.) I don't think we should touch anything related to docusaurusv1 yet, but when we do, the only thing we should do it remove it from the repo. With that said, there are higher priority things than removing v1 from the codebase I think we should focus on (translation issues, redirect problems, dev server, etc), as having v1 in the codebase doesn't add any additional overhead to anything.

A general approach could be:
i. wikiops gets merged to master
ii. change wikiops to dev - dev is used for staging/testing
iii. clean up v1

i. what is the point of having wikiops as a seperate branch? it seems to just delay new things getting added to master/dev. As each thing comes up, it should get merged in immediately after approval from team members.
ii. why do we change wikiops to dev instead of just creating a new branch off of master? I think separating dev and prod is important, but a simple master -> deploy to dev server, and prod -> deploy to prod (with rule that the only way things get added to prod is via a PR merging master into prod) should suffice (unless you really want a dev branch, in which case we always merge master into dev and never commit directly on dev just like we would do with master and prod.)

@emresurmeli @DrW3RK can I get your input as well?

[salmad3]

@jakehemmerle

• v1 doesn't have to hold any static docs or actual wiki content - just web related files. Up until version 2 is good it can serve as a backup. It's also not being prioritized over other issues.
• wikiops is just a branch to address some of these issues.
• Regarding master, prod, dev - my mistake, I wrote it out incorrectly. But I don't think master -> staging -> prod is necessary. What I meant to get at was: staging -> master (prod). dev wasn't the right name, more like qa, which would used for staging. PRs opened against qa -> stage and check, then -> master (acts as prod), and qa would created against master.

[jakehemmerle]

• v1 doesn't have to hold any static docs or actual wiki content - just web related files. Up until version 2 is good it can serve as a backup. It's also not being prioritized over other issues.

Cool we are on the same page. This was my point; we shouldn't touch v1 or move it out of master until we go to delete it, otherwise if do anything special with it (like removing it from master and keeping it in another branch or anything), and we need to do use it, we can't easily rebase it, we have to deal with all the CICD related overhead to make v1 run and then any structural changes (like doc and config stuff) that would need to get fixed manually

[salmad3]

You're right. Also realized the wikiops branch idea and trying to outpace updates to master isn't a good idea haha. The motive behind it was to "clean up" the repo, but also because as right now, both versions are submerged together - for instance, updating the README to specify "polkadot2" and "kusama2" instead of "polkadot" and "kusama", respectively, because of both being accounted for in the package.json, doesn't seem reasonable

[jakehemmerle]

@DannyS03 I agree that naming should be consistant; what do you say we swap out polkadot for polkadot1 and polkadot2 for polkadot? That would mainly just be the package.json file and the CICD actions right?

[salmad3]

That sounds good. Right those should only be the things to update

[salmad3]

Folder structure should be prioritized: #2415 (comment)

[salmad3]

@nam-hle #2442 (comment), any suggestions would be much appreciated

[salmad3]

@nam-hle it seems like injections still aren't getting recognized, for instance: https://wiki.polkadot.network/docs/learn-identity

[nam-hle]

Hi @DannyS03, as I said before, the Markdown parser misunderstood between our variable underscore and italic one. It can be fixed easily by changing italic underscore to asterisk. But I suggest to use camel convention for our variable to fix the issue permanently. What do you think?

[salmad3]

It seems like we've tackled the immediate tasks related to "wikiops" up until this point, where IPFS related tasks has an issue of its own that is tracking progress. Because of recent updates we have encountered redirect conflicts (being warnings more than anything), which is also tracked by more than one issue at the moment.