We only needed to understand the basic workflows in order to get started versioning documents with Git. But the good news was that we didn’t have to worry too much about all those features. It had many advanced features as well as commands that could accept arguments. It looked too unfamiliar and complicated. In the beginning, adopting Git looked like yet another challenge on top of the mountain we were already facing. This meant that they couldn’t leave any comments or suggest any changes… unless they sent their feedback via email, which is really inconvenient.Īnd then we migrated to an internally built IntelliJ-based toolset – an early prototype of what’s now known as Writerside and decided to switch to Git. We basically just sent the developers a link to a staged version, not the source code. The review process was practically non-existent. This meant there was no conflict resolution process, little collaboration within the writers’ team, and absolutely zero collaboration with developers.
Intellij dataspell download#
Kindly download the latest version from the depot”. Whenever one of us needed to make changes to a common configuration file – the one that declared the Table of Contents, for example – we’d write a message to our Skype chat (there was no Slack in those days) saying something like: “I’m checking out file X for editing, please don’t touch it until I’m done.” And then, once we’d finished, we’d write: “I’ve checked it back in. Each writer owned a portion of the documentation related to a specific area, subsystem, or product, and we rarely contributed to each other’s files. There was no single source of truth as to which features would go into the release version, there was little forward planning, and our tasks were often random and haphazard.ĭeveloper sources were stored in a Git repository and documentation sources were versioned by Perforce.
If they added it to the issue, we’d document the new functionality, but if they ever forgot to tag it – “helaas pindakaas”, as they say in the Netherlands. The process we had for documenting new features was as follows: there was a “To be documented” tag in our internal issue tracking system, YouTrack, and it was the developers’ responsibility to put this tag on any issue that they thought affected documentation. We’d see them at the daily IntelliJ IDEA standup, but the team was already several dozen strong, and we didn’t feel like boring them with the details of our humble routine. We sat together in a separate room and kept our door closed most of the time, rarely mingling with any developers. When I joined JetBrains back in 2014 as a senior technical writer, our team consisted of 5 documentarians covering 6 products.
0 kommentar(er)
