Wiki, website, and stuff..
I was contemplating editing the release schedule documentation < https://svn.boost.org/trac/boost/wiki/ReleaseSchedule> and thinking if it would be better to start moving such documentation away from the Trac wiki. And I think it is a good idea to move that documentation elsewhere. Especially if it's some place where it's easier to manager the editing permissions and contributions. So I was thinking about what options we had. What I'm aware of as choices are: * Another project in Github just for wiki like documentation. * Using the website project wiki for it. * Adding it directly to the website given how easy it is to edit online now. Although not so easy to preview because of the way the web site works. * A github pages site of some sort. Are there other options? Any opinions on the above options? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On Tue, Jan 27, 2015 at 10:42 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
I was contemplating editing the release schedule documentation < https://svn.boost.org/trac/boost/wiki/ReleaseSchedule> and thinking if it would be better to start moving such documentation away from the Trac wiki. And I think it is a good idea to move that documentation elsewhere. Especially if it's some place where it's easier to manager the editing permissions and contributions. So I was thinking about what options we had. What I'm aware of as choices are:
* Another project in Github just for wiki like documentation.
* Using the website project wiki for it.
* Adding it directly to the website given how easy it is to edit online now. Although not so easy to preview because of the way the web site works.
* A github pages site of some sort.
Are there other options? Any opinions on the above options?
There are really two issues IMO: * Docs primarily for release managers. We already have the boostorg/release repo, so we can either add release manager docs to its directory tree or use its wiki. The wiki approach encourages all release managers to help keep the docs up-to-date. Docs in the directory tree brings all the advantages of git distributed version control, and we can also use gh-pages mechanism. The wiki approach is somewhat lighter weight and so may be better for casual documentation. * Other trac wiki pages: I don't think there is a single answer. Each subset of pages needs to be looked at since some should be abandoned, some moved to a boostorg or boostorg/project wiki, and some (like developer related docs) should probably go in either the super-project repo or a new developer repo. --Beman
On Wed, Jan 28, 2015 at 1:52 PM, Beman Dawes <bdawes@acm.org> wrote:
On Tue, Jan 27, 2015 at 10:42 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
I was contemplating editing the release schedule documentation < https://svn.boost.org/trac/boost/wiki/ReleaseSchedule> and thinking if it would be better to start moving such documentation away from the Trac wiki. And I think it is a good idea to move that documentation elsewhere. Especially if it's some place where it's easier to manager the editing permissions and contributions. So I was thinking about what options we had. What I'm aware of as choices are:
* Another project in Github just for wiki like documentation.
* Using the website project wiki for it.
* Adding it directly to the website given how easy it is to edit online now. Although not so easy to preview because of the way the web site works.
* A github pages site of some sort.
Are there other options? Any opinions on the above options?
There are really two issues IMO:
* Docs primarily for release managers. We already have the boostorg/release repo, so we can either add release manager docs to its directory tree or use its wiki. The wiki approach encourages all release managers to help keep the docs up-to-date. Docs in the directory tree brings all the advantages of git distributed version control,
One quick comment I would like to throw in here: Wikis on GitHub are stored in Git repositories and come with all advantages of git distributed version control.
and we can also use gh-pages mechanism. The wiki approach is somewhat lighter weight and so may be better for casual documentation.
* Other trac wiki pages: I don't think there is a single answer. Each subset of pages needs to be looked at since some should be abandoned, some moved to a boostorg or boostorg/project wiki, and some (like developer related docs) should probably go in either the super-project repo or a new developer repo.
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Daniel Pfeifer Sent: 29 January 2015 09:11 To: Boost Developers List Subject: Re: [boost] Wiki, website, and stuff..
On Wed, Jan 28, 2015 at 1:52 PM, Beman Dawes <bdawes@acm.org> wrote:
would be better to start moving such documentation away from the Trac wiki.
* A github pages site of some sort.
Are there other options? Any opinions on the above options?
There are really two issues IMO:
* Docs primarily for release managers. We already have the boostorg/release repo, so we can either add release manager docs to its directory tree or use its wiki. The wiki approach encourages all release managers to help keep the docs up-to-date. Docs in the directory tree brings all the advantages of git distributed version control,
One quick comment I would like to throw in here: Wikis on GitHub are stored in Git repositories and come with all advantages of git distributed version control.
I think that 1 Documentation that is correct, updated and understandable is Really, really, really important - and we could do better. 2 Wiki documentation has the big advantage that anyone (with a login - not anon) can update - so updates and correction are more likely to be done. 3 GIT allows us to easily back up to previous versions if a change proves unhelpful. So I support Wikis on GitHub are stored in Git repositories. (How we deal with the bug reporting aspect of Trac, I am not so sure.) Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On Thu, Jan 29, 2015 at 4:11 AM, Daniel Pfeifer <daniel@pfeifer-mail.de> wrote:
One quick comment I would like to throw in here: Wikis on GitHub are stored in Git repositories and come with all advantages of git distributed version control.
Thanks! That's important and I wasn't aware of it. As an experiment, I'll move the release manager's checklist to the release wiki on GitHub, and report back. Thanks, --Beman
participants (4)
-
Beman Dawes -
Daniel Pfeifer -
Paul A. Bristow -
Rene Rivera