From: Michael Tremer <michael.tremer@ipfire.org>
To: documentation@lists.ipfire.org
Subject: Re: IPFire Wiki Workflow
Date: Sun, 28 Jul 2013 18:27:09 +0200 [thread overview]
Message-ID: <1375028829.18293.29.camel@rice-oxley.tremer.info> (raw)
In-Reply-To: <E6D9508B-AB99-48F0-86B1-538458BE985B@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 3999 bytes --]
Hey Erik,
great that you are back from traveling and that we can finally go on
with this one.
On Sat, 2013-07-27 at 18:00 +0200, Erik K. wrote:
> Hi Michael,
> so for the first i think your workflow looks pretty good, but i have some possible enhancements how to extend this workflow.
> - The developers and their new developments should become also a part of Point (A) i think. Stevee shows a good way how a short developer hand out could looks like, take a look in here --> http://wiki.ipfire.org/en/configuration/network/dnsforward . So the coordinator needs to know about this changes too that he can define a priority in the topics.
The idea is right, that developers should create a small page with the
most essential information about a new feature, but I don't see how this
is involved in the workflow of the documentation team.
I think we should work on an extra development workflow and at the end
of that, it should be mandatory to create that page and send the
information about the existence of that to the wiki coordinator.
Basically, this happens independently from the documentation workflow.
> - In point (B) shouldn´t be not also the german translations in there as a point (2) ?
No, the idea is to write the content in English first. And after that
has been finished and been reviewed (C), we start translating.
I guess the translation teams will organize themselves in a way they
like. They are usually much smaller and do not need a lot of
coordination.
The workflow implies one very import thing: English first.
No content is ever created first in any other language than English.
After it has been reviewed, we start translations into second languages.
> - The testing of the written articles should be mentioned i think, cause it is not enough to understand what this software should do, the software needs to be tested in every single function so a quality management will be done too.
This should be part of the review.
> --> I think a new guideline for new and old wikis should be to explain every function which can be seen on the WUI, this means especially the core development or addons where a GUI was also developed by the IPFire team..
> --> Addons with foreign documentations can also become a short docu, but they should be linked to the external wiki/docu. This should also be a part of a guideline too.
To give a short answer on this: We should not copy content or write
articles about things that are not part of our business. Just link to
it.
We should discuss some general styling guidelines after we have proved
that the desired workflow is actually working.
> A question: Should i start as a coordinator to list some important topics ? Or do we need a little longer ?
This list should be open (as basically everything). I suppose it's best
to create an extra wiki page for that and write down what needs to be
done. In addition to that we should set a priority and write down notes
about what particularly needs to be improved on an article.
Here are two things that are due until the release of the next core
update, which will be roughly 2 weeks. Possibly less.
* Wireless Client on RED
* DNS Forwarding GUI
>
> ------------------------
>
> A guideline of how to structure the content and the layout of the wiki might be important for the workflow i think. This should prevent that people doing very different stuff if they work together in the same sections. So i have found until now 2 different guidelines for the IPFire wiki.
>
> - http://wiki.ipfire.org/nonpublic/en/guidelines
> - http://wiki.ipfire.org/en/edit
>
> So some questions to you all regarding to this theme:
> - What kind of layout and content structure we should use ?
> - What things are missing in those guidelines ?
> - To make one good guideline please give some suggestions to them.
Let's discuss that later and let's focus on the content right now.
Best,
-Michael
next prev parent reply other threads:[~2013-07-28 16:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <D8D682F2-7C9C-4962-AA0E-9AD00D3D5003@ipfire.org>
2013-07-12 14:55 ` Michael Tremer
2013-07-27 15:25 ` IPFire Wiki Workflow - list of why it can be interesting to be in a documentation group Erik K.
2013-07-27 16:00 ` IPFire Wiki Workflow Erik K.
2013-07-27 16:50 ` Erik K.
2013-07-28 16:27 ` Michael Tremer [this message]
2013-07-12 17:50 ` R. W. Rodolico
[not found] <CBA641A3-39FA-42D7-93D2-240B22AF1F79@ipfire.org>
2013-08-02 12:01 ` Michael Tremer
[not found] <ED6F7E1F-7128-485B-8365-98F6674459B4@ipfire.org>
2013-07-12 12:06 ` embp
2013-07-10 9:46 Michael Tremer
2013-07-11 7:28 ` R. W. Rodolico
2013-07-11 10:01 ` Michael Tremer
2013-07-11 16:18 ` R. W. Rodolico
2013-07-11 17:30 ` Erik K.
2013-07-11 17:54 ` Erik K.
2013-07-11 22:01 ` Michael Tremer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1375028829.18293.29.camel@rice-oxley.tremer.info \
--to=michael.tremer@ipfire.org \
--cc=documentation@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox