Somebody’s gotta ask the first question. 
I am currently developing in password protected space for now… my understanding is that the whole project is either password protected or not.
- I’d like an internal sandbox for collaboration before a doc goes out into the world (with or without a password). I tried hiding developing work under an older version, but I’m not really satisfied with that. The team of folks with whom I’m working is under 20 at this time, but changes with some regularity. If I upgrade to the Grow plan, I can collaborate without publishing.
- Alternately, I could create a separate project on the Seed Plan, and work out of there for development, then export/import to the full site for external publication. I could publish under one password for development, and not worry about admin-ing the changing accounts of the folks with whom I collaborate.
Either one gets me where I want, I suppose… and it winds up costing about the same in the end. Which is the better way to do this?
Thanks!
Hey Randy,
Welcome to DeveloperHub and thank you for posting the first question!
I understand that you need to have different access levels for engineers to your documentation in order to make sure that the non-writers do not edit the content.
Using another seed plan and providing the engineers with the customer-facing login password is a good idea, however when engineers leave the organisation, you would have to handle changing the password and distributing it again. Also, you’re limited to 1 documentation per version, which might limit you at some point.
Upgrading your existing plan to a grow plan not only gives you unlimited DeveloperHub documentation, and 20 users, but you get the full customisation. Sooner or later, we find that our customers with big documentation would like to add more branding touch to their sites. Admin-ing accounts might be a little bit tiring if engineers change fast, but adding/removing teammates is really a two click operation (no drilling down between pages like other online services), and even your teammates can add teammates. It would provide you with more security on the long run.
Now regarding different access levels, we are aiming at implementing different user roles, including a Read+Comment access role. I’d expect this around late Q3, early Q4. This should hopefully solve your problem entirely.
Hope this helps
Thanks, Zaid! I rather like finding that by the time I think of something, you’re already working on it. Different access levels between external audience, internal reviewer, and author – that would work well for me. That’s gotta be the long-term plan for reasons of scale.
I can handle the simple password admin for a Seed Plan in the near-term when the reviewer team changes. Thanks for reminding me that staff change should initiate a password change, as well. I’d plan to cut over to the Grow Plan when the Read+Comment role goes live.
What is a ‘documentation’ in context to hierarchy? I understand Project, Versions, Page, and Sub-page levels, as well as how Categories can be used to organize Pages. There’s one Documentation per version – is the limiter here really page length (specifically as it relates to navigation columns?
Sounds like we should spin up another thread for access levels!
Regarding “documentation” in context to hierarchy, quoting from “How are projects structured?”:
Projects are at the top of the hierarchy. Each project contains the following:
- A team of collaborators.
- A landing page.
- One or many versions.
Each version acts as a container for:
- One or many documentation.
- One or many references.
Each documentation contains:
- One or many pages, categories and external links.
Versioning examples would be “v1.0”, “v1.1”, where when your product/API changes, you’d clone the entire previous version, and provide a new one detailing the new changes.
Documentation, provides an extra level of hierarchy that can be used depending on the complexity of your project. For example, if you are delivering multiple SDKs to your customers, and each SDK is heavy, then you might have an “Android SDK” documentation and an “iOS SDK” documentation. The difference between documentation and version is that version is cloneable, copying previous content, while documentation is brand new content. Some other customers use extra Documentation for change logs, FAQs, different kinds of guides, all under the same version. Other customers who provide hardware solutions, use a separate Documentation for each hardware product guide. Mainly, you’d use it to offload content and better organise it from a central place.
Ah, got it. Thanks for citing the doc — as a doc guy, I like knowing where it is. I looked and couldn’t find it before. This is well-said: The difference between documentation and version is that version is cloneable, copying previous content, while documentation is brand new content. I see how that could provide significant flexibility at scale.
Thinking more on this… I have a suite of software whose elements will advance in parallel (all tools at V1, then all tools at V2, then all tools at V3, etc.). For the same company, but with a dramatically different and non-synchronized cadence, we have a SDK whose documents won’t frequently (if ever) match the versions of the software suite.
Looking at the way versions are implemented in DeveloperHub, is the best way to do this by use of a separate project? Leave it to me to find an odd in-between case. 