Please no, wiki's suck for quality documentation. Anyone can put whatever rubbish they want there.
On Thu, 6 May 2021 at 14:41, 'Olblak' via Jenkins Infrastructure < [email protected]> wrote: > Hi Everybody, > > During the last Infrastructure meeting > <https://github.com/jenkins-infra/documentation/blob/main/meetings/2021-05-04.md>, > Daniel Beck came with an interesting question. > > Considering the proliferation of Google documents and other random tools > to take notes, > shouldn't we consider bringing back Confluence? > > While I am not convinced that a wiki is THE solution, I definitely share > his frustration. > I feel we did a major step backward in terms of knowledge management > across the Jenkins project. > > Nowadays, the default behavior is to create a Google document to take > notes during meetings or event organizations. > This approach is very easy for synchronous collaboration but it also has > bad side effects. It's difficult to find old documents unless you > bookmarked them. And, documents lifecycle are affected by the "new" google > storage policy or corporate google accounts. > > Historically, we used the wiki to take notes and write documentation. > https://wiki.jenkins.io/display/JENKINS > That central place was really convenient to share and find information > across community initiatives. > > That being said, I didn't forget the reasons to move away from Confluence, > and here are some of them: > > 1. Spammers, because of the nature of the Jenkins project we tend to > attract a lot of spammers. Then *someone* has to do some clean-up. > 2. Maintaining confluence is a major distraction that nobody wants to do. > 3. Confluence in the current state is very slow mainly due to point 2 and > due to unfinished infrastructure work. > > The two last elements could be solved by asking the Linux Foundation to > maintain Confluence. The same way they do for Jira > <https://issues.jenkins.io> > Also, it's worth keeping in mind that Atlassian is deprecating their > on-prem solution in 2024. > > Several weeks ago, I started an experiment on the infrastructure project > to use hackmd.io to allow synchronous collaboration on meeting notes. > During a meeting or a maintenance window, everybody can participate then > at the end of the meeting someone pushes the notes to a git repository like > https://github.com/jenkins-infra/documentation/#documentation > To me it combines two approaches, it's as easy as a Google document to > collect notes and then we can easily store them on a git repository > directly in Markdown. > Unfortunately, I am not convinced by the asynchronous collaboration > workflow. > > There is a demo here - https://youtu.be/1s2Y3aPXTOI?t=126 (Sorry for the > poor video) > > As I said it's an experiment, the purpose is to simplify synchronous > collaboration and then persist the content on a git repository that can > easily be browsed. > > I would be curious to know your feeling about all of this and if you have > other suggestions. > > Cheers > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Infrastructure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/jenkins-infra/7fc740e9-3cfd-4daf-bb0d-44b7a8564930%40www.fastmail.com > <https://groups.google.com/d/msgid/jenkins-infra/7fc740e9-3cfd-4daf-bb0d-44b7a8564930%40www.fastmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BidiAX87%2BDenOYkqw2ArtQCc6HRXpNZ-r4To5gh2vNC7aQ%40mail.gmail.com.
