On Wed, Jul 08, 2015 at 11:32:46AM -0400, Jeff Darcy wrote: > > My suggestions: > > > * Differentiate between user doc(installation, administration, feature > > summary, tools, FAQ/troubleshooting etc) and developer doc(Design doc, > > developer workflow, coding guidelines etc). > > I think there's a third category: feature/release planning and > tracking. That stuff doesn't belong in the online equivalent of a > manual, though it should be linked from there. It also doesn't belong > in the same git repository with code, because it's explicitly not > associated with a particular version of code. However, putting it in a > *separate* git repository might work. Indeed, and I value tracking of who made comments a lot. Developers that are used to Gerrit can checkout a document, update it and push the new version for review. Feature and release planning is very much only done by developers, and they use Gerrit for their patches already too. Mostly the same workflow as they are used to, should make adoption easy. > Having history would be nice. Gerrit and github both provides > reasonable inline-commenting facilities to support the kinds of > discussions that need to occur, plus a way to finalize the results of > those discussions with a commit. I do not agree that commenting in GitHub pull requests is usable. Comments get lost when a new version of the patch is posted, unless you have the URL to the actual git-commit of the previous version. This is one of the reasons why NFS-Ganesha moved from a GitHub based workflow to Gerrit. > My main concern is that such a setup might seem inaccessible to users > who aren't familiar with those developer-oriented workflows. For them, > probably nothing more cumbersome than a wiki would be sufficient. On > the other hand, I have yet to see such a user edit one of our > feature/planning pages even when those were in a wiki. I can barely > get my fellow developers to do so, even when the features are their > own, so maybe usability just isn't the issue. Yeah, I have the same impression. Lets make it easier for developers to update the feature pages while they work on the planning/design. Depending on less different tools or hosted services would be an advantage IMHO. > > * User documentation goes to glusterdocs repo and developer documentation > > stays in gluster repo. Makes sense to me. > > * An user/admin who installed through packages can do a man(and find man > > pages) or google(and find readthedocs pages) without going through > > gerrit/wiki etc. Yeah, and installing offline documentation might become possible too :-) > > * A developer who has cloned gluster repo finds all the development related > > info in the repo itself(git grep etc) and does not need to go out of the > > code base. Yes, there are some good bits about mem-pool and bitrot under the doc/ directory in the sources. I do not see a sensible use for those outside od the source tree. Changes to mem-pool or bitrot would also need to update the docs, we should try to prevent getting those out of sync. > > * A patch which changes a struct member should change the relevant developer > > documentation in the same patch set. +1 > > * A patch which changes a user facing behavior should be ideally followed by > > a PR on glusterdocs repo. (patch owner and feature maintainer to ensure > > that). I would also add the component maintainers to the list who should be responsible for making sure the documentation gets addressed. I guess the glusterdocs repo on GitHub uses the "Issues" instead of Bugzilla? For each feature we should then at least file a GitHub issue there. > > * Use github's PR for glusterfsdocs and hence use the comments system on > > github for that. Yeah, and the documentation maintainers should involve the component maintainers for reviewing those proposed changes. Not sure how to add someone on CC of a pull request though... > > * A developer doc change or a new feature proposal should be as patch on > > gluster repo and we can use gerrit's inline comments for discussion on that. Like Jeff mentioned above, new feature documentation might be more useful to start in its own git repo. I think this would make it easier to integrate with the readthedocs stuff. How its done does not matter much to me (now at least), I'm all for using Gerrit to review proposed features and planning documents. Thanks, Niels _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
