Where do we want have "global" wiki for platform?

[iloveeclipse]

Since the "old" eclipse.org wiki will be discontinued sooner or later, where do we maintain such generic, very valuable & important information like below?

• https://wiki.eclipse.org/Version_Numbering
• https://wiki.eclipse.org/Evolving_Java-based_APIs
• https://wiki.eclipse.org/Evolving_Java-based_APIs_2
• https://wiki.eclipse.org/Evolving_Java-based_APIs_3

Here: https://github.com/eclipse-platform/.github/wiki ?

[akurtakov]

That's our best option.

[mickaelistria]

What about moving it to a documentation folder under the eclipse.platform repo? Or into a new platform-wikidoc repo? I like the idea of being able to account documentation contributions as much as code contributions, and the ability to encourage review when editing documentation. A wiki is IMO too lax and can easily turn "bad" on the long run if random people put there random content (I curated SWTBot wiki a while ago, and there were a lot of incorrect content on it that committers would probably have avoided and fixed if review were encouraged)

[jonahgraham]

I am not in favour of the built-in wiki on GitHub - it is somewhat limited and provides no way for contributors to provide updates.

Instead adding it to a documentation directory in the main platform repo seems like a good plan.

[fedejeanne]

FWIW it is possible to maintain the wiki pages "just like code", see this wiki page (pun intended), which would enable reviews, ease up the maintenance and hopefully provide better quality.

I'm only curious if it would be possible to somehow "link" the wiki across all repos in the same GH organization so one does not have to navigate to the correct repository before even seeing the "Wiki" Tab. I noticed eclipse-platform has its wiki in the repo .github and eclipse-jdt has it under eclipse.jdt.core, which is somehow confusing.

I am not in favour of the built-in wiki on GitHub - it is somewhat limited and provides no way for contributors to provide updates.

@jonahgraham which functionality are you missing?

[merks]

I expect this is done by otterdog and is only disabled because it's explicitly set that way:

https://github.com/eclipse-platform/.eclipsefdn/blob/bb83d80cb7445c18dab63052d920f1ef3dfadfbc/otterdog/eclipse-platform.jsonnet#L80

[jonahgraham]

@jonahgraham which functionality are you missing?

• There is no way for a contributor to propose a change to the GH wiki, i.e. you can't make a PR for the wiki and it can only be edited by committers (members in GH parlance)
• The files can be stored in such folders, but the wiki on GH is "flat" - i.e. you can't have the same page name in multiple folders.

[fedejeanne]

Good points. I was mistaken before when I said that it is possible to maintain the wiki pages "just like code", thanks for pointing that out.

Another option would be to disable the wiki and move all its content to a (new?) repository in the organization. We could then manage the content with the same workflow as the code and we could even use GH Pages to let Search Engines index it (see https://docs.github.com/en/communities/documenting-your-project-with-wikis/about-wikis)

What do you guys think?

[mickaelistria]

I like this idea, although I don't think we need a new repo, we can use the .github one or the releng.aggregator for common documentation, and use individual repos for more specific information.

[jonahgraham]

Hmm - for the previous migrations I have done to GitHub (Planning Council, SimRel, CDT) I left it as a future thing to do GH Pages because I didn't want the overhead assuming that someone can do that in the future...

use GH Pages to let Search Engines index it

...but actually we should have this stuff in the index-able web so I now lean heavily on the idea that we should move directly to GH pages (with links back to the source for contributions).

[akurtakov]

I have transfered to releng.aggregator one as eclipse.platform.releng repo is empty and merged into aggregator one so should no longer be used for new development/discussions/documentation/etc.