Dave's mail:
Hey Paul,
I was reading http://allura.sourceforge.net/migration.html Thanks for
writing those up. On the last section about the actual import,
"support channel for SourceForge.net" and such are mentioned. But in
theory the allura docs should be agnostic of the SF.net
implementation. There's a large overlap of docs between Allura
platform and SF implementation. Another example is
https://sourceforge.net/p/forge/documentation/API%20-%20Beta/ which is
useful for the platform too. I'm not sure the best way to store these
docs so that they are available for both the platform and the site in
a way that makes sense. One idea would be to have the SF docs have
many links over to the Allura docs.
Anyway, back to the migrations. In that last section, can you change
it to describe how server admins create the migration API keys? We
need to know how to do that anyway. Then, under the API section of
https://sourceforge.net/p/forge/documentation/ToC/ do you want to
create a new small page with the info about requesting an import api
key from SF Support, and a link to
http://allura.sourceforge.net/migration.html for the rest of the docs?
Let's do this soonish, so it can help whomever does [#1786]
Related
Tickets:
#1786Described procedure for generation of API tickets in ps/1824, waiting for wiki edit access to create a page with SF.net user facing instructions.
Added wiki page https://sourceforge.net/p/forge/documentation/Project%20Import/ , I however filed it under "C. Managing your project", as it seems more related to project administration than API access (and corresponding section in "Classic setup" has "Exporting project data")
Oh, and I also took freedom to present import as "early access program", which I guess, makes sense, given complexity of the thing (it's easy to just migrate data, it's much harder to migrate data the users want them).
Merged branch, republished to allura.sf.net