Orphaning FreeIPA guide
by Martin Kosek
Hello all,
FreeIPA project is already for some time without sufficient resources to revive
and maintain our former long upstream user guide. We did not find enough
manpower either in FreeIPA developer nor our users community, so we decided to
stop maintaining it.
Detailed justification including links to mail threads in:
http://www.freeipa.org/page/Upstream_User_Guide
I would like to avoid leaving any loose ends on Fedora Documentation project
side, do you have any recommendation for us? I already closed respective
Bugzillas and upstream Trac tickets with explanation. Should we also orphan the
guide in
https://fedoraproject.org/wiki/Docs_Project_meetings#Guides
or on any other locations? For starters, I think we should close the
"freeipa-guide" component of "Fedora Documentation" as nobody from our team
would be responding there.
Thanks for any advise.
--
Martin Kosek <mkosek(a)redhat.com>
Supervisor, Software Engineering - Identity Management Team
Red Hat Inc.
7 years, 4 months
introduction - Ryan
by Ryan Gough
Hi Everyone,
I'm looking at getting involved in the project as I have been a long
time user of Fedora (e.g. since Core 1) and would like to start
contributing. My name is Ryan, I'm from Western Australia (GMT+8). I
am an IT technician and have been using linux as a hobby since 2k4
(using RH9). I have also had the opportunity to work with RHEL in my
job during a project as well as having worked with a couple of other
distros. In my line of work I have often needed to produce
documentation to a professional standard and I feel I can contribute
this way currently. I believe I should be able to contribute 4 hours a
week at this point in time.
Regards,
Ryan
irc: _terminal_
FAS: t3rm1n4l
7 years, 6 months
[fedora-badges] #259: Fedora Cookbook Contributions
by fedora-badges
#259: Fedora Cookbook Contributions
-------------------------------------+-------------------------------------
Reporter: | Owner:
immanetize | Status: new
Type: | Keywords:
New badge idea | Has a description: 0
Priority: | Artwork status: None
minor | External requirements:
Has a name: | Triaged (triagers only): 0
1 |
Concept approved (reviewers only): |
0 |
Badge definition status: |
Full, needs review |
Manually awarded: |
0 |
-------------------------------------+-------------------------------------
What the badge should be granted for:
Contributing "recipes" to the Fedora Cookbook:
1 submission: Cookbook I: Commis
- "You had a recipe published in the Fedora Cookbook. Appetizing!"
5 submissions: Cookbook II: Tournant
- "You have published 5 recipes in the Fedora Cookbook. Tasty!"
15 submissions: Cookbook III: Grillardin
- "You have published 15 recipes in the Fedora Cookbook. Delicious!"
30 submissions: Cookbook IV: Saucier
- "You have published 30 recipes in the Fedora Cookbook. Scrumptious!"
50 submissions: Cookbook V: Sous Chef
- "You have published 50 recipes in the Fedora Cookbook. Delectable!"
100 submissions: Cookbook VI: Chef de cuisine
- "You have published 100 recipes in the Fedora Cookbook. Decadent!"
150 submissions: Cookbook VII: Gourmand
- "You have published 150 recipes in the Fedora Cookbook. Beefy!"
Badge names borrowed from http://en.wikipedia.org/wiki/Brigade_de_cuisine
, suggestions for improvement on names and patter are welcome. Some
dining-related artwork would be greatly appreciated.
Submissions are reviewed and committed manually, so the badges will have
to be manually awarded as well. Anyone in docs-writers should be able to
award these badges.
--
Ticket URL: <https://fedorahosted.org/fedora-badges/ticket/259>
fedora-badges <https://badges.fedoraproject.org>
A place to collect and debate badge ideas for the Fedora Badges app
7 years, 9 months
[Bug 1008149] New: Contraficting info about the need of shared storage for storing guest images to be migrated
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1008149
Bug ID: 1008149
Summary: Contraficting info about the need of shared storage
for storing guest images to be migrated
Product: Fedora Documentation
Version: devel
Component: virtualization-getting-started-guide
Assignee: dayleparker(a)redhat.com
Reporter: jrodrigosm(a)yahoo.es
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: dayleparker(a)redhat.com, docs(a)lists.fedoraproject.org
Hi,
In the Fedora 19 "Virtualization Getting Started Guide", section 2.2 ("What is
migration?"), URL
http://docs.fedoraproject.org/en-US/Fedora/19/html/Virtualization_Getting...
In the paragraph right before the 2.2.1 title, it is stated that "In Fedora 19,
shared storage is not necessary for storing guest images to be migrated. With
live storage migration [...]".
But in the last paragraph of the page, right before the note, it is stated that
"Shared, networked storage must be used for storing guest images to be
migrated. Without shared storage, migration is not possible."
These two statements seem contradictory to me. I just started learning about
virtualization, so I am unable to propose an alternative. But I do think some
clarification is needed.
Thanks,
Rodrigo
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=QwkGtwKvp5&a=cc_unsubscribe
8 years, 1 month
[Bug 846864] New: Need a list of toolsets and when they are appropriate in the virt Getting Started guide
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=846864
Bug ID: 846864
QA Contact: docs-qa(a)lists.fedoraproject.org
Severity: unspecified
Version: devel
Priority: unspecified
CC: docs(a)lists.fedoraproject.org
Assignee: laine(a)redhat.com
Summary: Need a list of toolsets and when they are appropriate
in the virt Getting Started guide
Regression: ---
Story Points: ---
Classification: Fedora
OS: Unspecified
Reporter: laine(a)redhat.com
Type: Bug
Documentation: ---
Hardware: Unspecified
Mount Type: ---
Status: NEW
Component: virtualization-getting-started-guide
Product: Fedora Documentation
The Getting Started Guide needs an overview of all the different toolsets, and
when each would be appropriate. In particular I'm talking about the following:
1) gnome-boxes
2) virt-manager
3) virsh, virt-install
4) ovirt
5) Should we point some people to OpenStack?
I will write up a first draft of this, and hand it to a qualified docs person
to edit and correctly place in the guide.
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 5 months
Re: [proposal] Fedora Developer Portal
by Pete Travis
On 05/27/2015 08:57 AM, Adam Samalik wrote:
> Hello everyone!
>
> I would like to make a proposal about new project: a website for Fedora developers.
>
>
> === Why? ===
> - Fedora does not have a page targeted on developers like developer.ubuntu.com or developer.apple.com
> - Developers have no place to find out about interesting projects like Copr, Developer Assistant, etc.
> - There is also no place with guides and help on how to get things up and running
> - Current fedoraproject wiki is not designed for app developers, 'developers' on wiki essentially means Fedora packagers
> - There is no place for downloading (promoting) Docker images and Vagrant boxes based on Fedora
>
>
> === What? ===
> Create a new page: developer.fedoraproject.org - a new go-to place for app developers running Fedora.
>
> The web page has would show beginners or advanced users how to install a new features on Fedora and what to do if they want to start developing something in Fedora.
>
> The main categories could be something like these:
> 1. Development tools:
> - Vagrant, Developer Assistant, ...
> - Which tools to use for development and how they can help me
> - explain WHAT the project is and HOW to get it running
> 2. Languages, technologies, runtimnes:
> - Python, Ruby, Rails, Perl, ...
> - Info about packages, the "I am a _ developer" view
> - explain WHAT the project is and HOW to get it running
> 3. Distribution/deployment:
> - Copr, Docker, Openshift, ...
> - How to get my project to people?
> - explain WHAT the project is and HOW to get it running
> 4. Docker images, Vagrant boxes, ...
> 5. Blogs
>
>
> Petr Hracek and Josef Stribny and I are starting this project and I will be the one responsible for it.
>
> Do you have any tips, recommendations or expectations about this project? Is there something you would like to see on the page? Let's start a discussion!
>
> Thanks!
>
> Adam Samalik
> Associate Software Engineer
> Red Hat
This sounds a lot like developer-focused documentation. The docs team
has been talking a lot about refocusing lately, and I had it in mind to
structure something that would provide appropriate content to users,
contributors, community members, and developers. It would be great if
we could combine efforts on this.
There's a rough concept in place that I've been *slowly* hacking at;
take a bunch of git repos containing source markup (ie one for each
current guide, one for the python SIG, one with fedora-infra SOPs, one
for the Server WG and edition, you get the idea) and process them. One
step validates and pushes strings to zanata for translation; another
renders to html and extracts some metadata, another step parses the
metadata to create a menu / site structure. The steps are run by
buildbot (maybe taskotron, eventually) and triggered by commits or
fedmsg signals, so content creators can simply write out a
ReStructuredText article without getting concerned about the publishing
process and presentation.
We've found that more people are willing to write - whether it's API
reference materials or general desktop usage - if their domain knowledge
can be the focus, and not documentation tooling and processes. We also
find that a git workflow enables better quality documentation and
fosters a sense of ownership and involvement, so the idea is to meet
halfway.
--
-- Pete Travis
- Fedora Docs Project Leader
- 'randomuser' on freenode
- immanetize(a)fedoraproject.org
8 years, 6 months
Re: [proposal] Fedora Developer Portal
by Pete Travis
On 05/28/2015 01:51 AM, Petr Hracek wrote:
> On 05/28/2015 08:27 AM, Pete Travis wrote:
>> On 05/27/2015 08:57 AM, Adam Samalik wrote:
>>> Hello everyone!
>>>
>>> I would like to make a proposal about new project: a website for
Fedora developers.
>>>
>>>
>>> === Why? ===
>>> - Fedora does not have a page targeted on developers like
developer.ubuntu.com or developer.apple.com
>>> - Developers have no place to find out about interesting projects
like Copr, Developer Assistant, etc.
>>> - There is also no place with guides and help on how to get things
up and running
>>> - Current fedoraproject wiki is not designed for app developers,
'developers' on wiki essentially means Fedora packagers
>>> - There is no place for downloading (promoting) Docker images and
Vagrant boxes based on Fedora
>>>
>>>
>>> === What? ===
>>> Create a new page: developer.fedoraproject.org - a new go-to place
for app developers running Fedora.
>>>
>>> The web page has would show beginners or advanced users how to
install a new features on Fedora and what to do if they want to start
developing something in Fedora.
>>>
>>> The main categories could be something like these:
>>> 1. Development tools:
>>> - Vagrant, Developer Assistant, ...
>>> - Which tools to use for development and how they can help me
>>> - explain WHAT the project is and HOW to get it running
>>> 2. Languages, technologies, runtimnes:
>>> - Python, Ruby, Rails, Perl, ...
>>> - Info about packages, the "I am a _ developer" view
>>> - explain WHAT the project is and HOW to get it running
>>> 3. Distribution/deployment:
>>> - Copr, Docker, Openshift, ...
>>> - How to get my project to people?
>>> - explain WHAT the project is and HOW to get it running
>>> 4. Docker images, Vagrant boxes, ...
>>> 5. Blogs
>>>
>>>
>>> Petr Hracek and Josef Stribny and I are starting this project and I
will be the one responsible for it.
>>>
>>> Do you have any tips, recommendations or expectations about this
project? Is there something you would like to see on the page? Let's
start a discussion!
>>>
>>> Thanks!
>>>
>>> Adam Samalik
>>> Associate Software Engineer
>>> Red Hat
>> This sounds a lot like developer-focused documentation. The docs team
>> has been talking a lot about refocusing lately, and I had it in mind to
>> structure something that would provide appropriate content to users,
>> contributors, community members, and developers. It would be great if
>> we could combine efforts on this.
> Hi Pete,
>
> you are right. it is developer-focused documentation which could
> be actualized based of top projects which are developed within Fedora.
> Do you have any content already which was done by docs team?
>
> Current top projects are I think Docker, Vagrant, DevAssistant.
No, we don't have any content in this area as far as I know. That
situation is a primary motivator for changing our tooling - the fact
that you're motivated to work up tooling and content independent of
Docs, without mention of a publican book, clearly demonstrates to me
that moving away from our Publican based site is a good choice. The
Docs team has experienced writers to help folks with the composition
process, and we want to enable the community at large to create
documentation that the current core writers don't necessarily have time
or domain knowledge for. The Fedora Project *should* have a system in
place where this kind of proactive idea can be put into play by filing a
ticket that says "Here is my repo of content, please publish it".
>>
>> There's a rough concept in place that I've been *slowly* hacking at;
>> take a bunch of git repos containing source markup (ie one for each
>> current guide, one for the python SIG, one with fedora-infra SOPs, one
>> for the Server WG and edition, you get the idea) and process them. One
>> step validates and pushes strings to zanata for translation; another
>> renders to html and extracts some metadata, another step parses the
>> metadata to create a menu / site structure. The steps are run by
>> buildbot (maybe taskotron, eventually) and triggered by commits or
>> fedmsg signals, so content creators can simply write out a
>> ReStructuredText article without getting concerned about the publishing
>> process and presentation.
> This is what I missed in my first proposal. Translation to different
languages
> can really be important for people which are not quite good in English.
>
> Like me;)
>
>>
>> We've found that more people are willing to write - whether it's API
>> reference materials or general desktop usage - if their domain knowledge
>> can be the focus, and not documentation tooling and processes.
> I think it can be a separate page like documentation.fedoraproject.org.
> API is a different issue.
> I htink that it can be covered and handled by developer.fedoraproject.org
> but developers which maintain API should also take care about the page.
>
My point here is that I would prefer an all-inclusive documentation
site. There can be separate sections for developers, users,
contributors - I had envisioned 'tabs' for these top level distinctions,
but design isn't my forte. The developer section can use the same
build infrastucture with the developer.fp.o domain on top if you like.
My concern is that now, when the Docs team is actively working to
address concerns around barriers to contributing, that a separate site
will fragment the potential contributor base.
> My first draft was create a template for fedoraproject.org for rest pages which will be developed
in future.
> Personally I think that current wiki [1] is not useless or not
readability for beginners and advanced developers.
>> We also
>> find that a git workflow enables better quality documentation and
>> fosters a sense of ownership and involvement, so the idea is to meet
>> halfway.
>>
> Nowadays we have a GitHub repository [2] which does not contain any
contents.
> Our idea is to use mechanishm like Jekyll and pages will be actualized
by pull-request.
>
> [1] https://fedoraproject.org/wiki/Fedora_Project_Wiki
> [2] https://github.com/phracek/developer-fedoraproject-org
>
So we're generally on the same page here; git repo with content, pull
requests managed by content stakeholders, publishing via static html
generator. There's some sentiment against Markdown, so I'm looking at
RestructuredText and docbook to start - but the idea is to support
diverse formats, so someone doesn't have the opportunity to refuse to
contribute because they will *only* write in $markup or will *never*
write in $othermarkup. I missed the link[0] in the first reply, sorry.
Much of the work so far has been setting up some reusable bits for
creating buildbot factories, and I'm learning to play with docutils lately.
[0] https://github.com/immanetize/anerist
--
-- Pete Travis
- Fedora Docs Project Leader
- 'randomuser' on freenode
- immanetize(a)fedoraproject.org
8 years, 6 months
