docs August 2016

docs@lists.stg.fedoraproject.org

19 participants
31 discussions

Fedora 25 Alpha Release Readiness Meeting, Thursday, August 18 @ 19:00 UTC
by Jan Kurik 15 Aug '16

15 Aug '16

Join us on irc.freenode.net in #fedora-meeting for the Fedora 25 Alpha Release Readiness Meeting meeting. The meeting is going to be held on Thursday, August 18, 2016 19:00 UTC. Please check the [FedoCal] link for your time zone. We will meet to make sure we are coordinated and ready for the Alpha release of Fedora 25 on Tuesday, August 23nd, 2016. Please note that this meeting is going to be held even if the release is delayed at the Go/No-Go meeting on the same day two hours earlier. You may received this message several times, but it is by purpose to open this meeting to the teams and to raise awareness, so hopefully more team representatives will come to this meeting. This meeting works best when we have representatives from all of the teams. [FedoCal] https://apps.fedoraproject.org/calendar/meeting/4486/ More information available at: https://fedoraproject.org/wiki/Release_Readiness_Meetings Thank you for your support and Regards, Jan -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

[Fedocal] Reminder meeting : Fedora Docs Weekly Meeting
by Pete Travis 15 Aug '16

15 Aug '16

Dear all, You are kindly invited to the meeting: Fedora Docs Weekly Meeting on 2016-08-15 from 14:00:00 to 15:00:00 UTC At fedora-meeting(a)irc.freenode.net The meeting will be about: An hour of docs folks talking about what they are working on and what they'd like to work on. More information available at: [https://fedoraproject.org/wiki/Docs_Project_meetings](https://fedoraproject… Source: https://apps.fedoraproject.org/calendar/meeting/371/

3 2

Re : Translation needs clarity on how to get updates published and the process.
by Jean-Baptiste 15 Aug '16

15 Aug '16

Thanks for this description and being careful about us. I suggest to do like websites : automatic publication with no manual action. It is the easiest and most up to date. But we need to understand you process, to know when content is moving and when it is stable, each letter you change is a correction we have to do in all languages. We are many people, but not many per language team. ----- Reply message ----- De : "Zach Oglesby" <zach(a)oglesby.co> Pour : <docs(a)lists.fedoraproject.org> Objet : Translation needs clarity on how to get updates published and the process. Date : ven., août 12, 2016 19:18 On Thu, Aug 11, 2016, at 09:34 AM, Brian Exelbierd wrote: > This email is to drive some discussion around $subject. It follows from > a blog soon to be posted on the Fedora Community blog > (https://communityblog.fedoraproject.org) The text below is copied > from that blog: > > Translation needs clarity on how to get updates published and the > process. > > This seemed like a communication problem between the two projects that > needed to be resolved with better docs on the process and hand-off > procedures. Because the tooling proposal will hopefully include > continuous deployment, this may become a lot easier in the future. > > Please reply here for discussion. > > regards, > > bex One of the goals of the new system is to handle publishing automatically, this will include translations that are ready to be published. Unfortunately, we do not have the final plan worked out yet, and I don't have a clear way to tell the translation team how it will definitively work, but I can explain my the idea I have worked out in my head and hope that it will help as we move forward. Step 1: Commits are made to a release branch of a document Step 2: The CI/CD system will run and create PO files push them to zanata Step 3: Translation team works on string in zanata as they do now Step 4: When a translation is ready to be published it is added to the configuration file Step 4: The config change is checked into the release branch and the CI/CD system is kicked off again and the new translation is added to the site. The only manual step in this whole process is to add the translations to the config once they are ready, but unfortunately I don't see a way past that to make sure we are not publishing translations that are not done or have not even been started. This step can be done a few ways. We can give translation team members access to the docs repos or we can use the pull request feature of Pagure, either way this is a much cleaner process than what he have now as a person only needs to be envolved one time in the build/publishing process to include a new translation.

3 2

How do we move to topic-based writing? Is there a plan?
by Brian Exelbierd 12 Aug '16

12 Aug '16

This email is to drive some discussion around $subject. It follows from a blog soon to be posted on the Fedora Community blog (https://communityblog.fedoraproject.org) The text below is copied from that blog: How do we move to topic-based writing? Is there a plan? After the FAD there was not a finalized plan, but planning began during this session. Many ideas were mentioned and consensus seemed to form around just writing new topic material. Folks from the Gnome project pointed out several reasons, including efficiency, for why they rewrote their materials when shifting from books to topics. Another benefit of starting from scratch is that new material can be written in a priority order possibly based on search keywords. One challenge here is that right now we have no place to put and publish these new topics. It was quickly pointed out that this is the "tools problem" and it has many solutions. Instead of letting tools be a blocker however, it was proposed to have people just write. "Write it in any format, any markup, any program, even on paper and just send it to us. We will get it published." This turned into a discussion of how many topics are also good for the Fedora Magazine. So the suggestion was made for folks to consider submitting material there first and we can pull it back into docs later. Additionally folks can email the docs mailing list or me. I am super excited to tell you I got an email with a topic 35 minutes after the session ended Please reply here for discussion. regards, bex

2 1

Re: Should we stop publishing the current guides now?
by Pete Travis 12 Aug '16

12 Aug '16

On Aug 12, 2016 10:12 AM, "Dylan Combs" <dylan.combs(a)gmail.com> wrote: > > I don't mean to just beat a perhaps-dead horse, but I really can't get past the opposition (which I don't understand) to a wiki-like environment for our documentation which would facilitate this very thing. > > I know there are concerns about "gardening" such a wiki, but seriously, if we can put in place a system similar to ask.fedoraproject.org where users are provided badges and karma for their work, I think that's the best we can do to promote user involvement in conjunction with an easy click-and-you're-in system for people to simply edit the content they're reading at that very moment, in real time. > > I know I would contribute heavily to such an environment. I contribute heavily to ask.fedoraproject.org in no small part because I can quantify my involvement, and this helps in a lot of ways people might not expect; I have even used my contributions to ask.fedoraproject.org as validation of my skills for my employer. reasons used it in job applications and resumes to demonstrate the quality of my writing and my ability to solve a variety of problems. > > If we could just simplify the documentation process by providing an easily-edited repository with a service that quantifies user involvement, that, in my estimation, is the best model for maintaining active, accurate documentation for our user base. It dramatically simplifies the involvement process (getting into6 ask.fedoraproject.org is so easy, new accounts pop up all the time, and contributions even from low-level accounts have been very valuable), it makes the whole thing accessible, and for long-term contributors, it provides a means by which to quantify and qualify their involvement in the Fedora community, and this is a feature that can be used by anyone for whatever purpose they may have. > > Our current system is extremely opaque, and the documentation is relatively static. We have to change that, in my opinion, and a simple Wiki with a user base consisting of moderators and contributors, managed by a karma and badge system, is the way to go. > > I only propose this, yet again, because I just don't see the rationale in its opposition. It seems to have elicited a few relatively enthusiastic notes of support from this distribution group along with a few somewhat vague concerns which I think have been addressed. > > Can we just chase this one down and prove that it is either unsuitable or valid as a solution for our issue? We gotta move on this! > > -Dylan > We did chase this down and determine that a wiki did not meet our needs, for a variety of reasons

2 1

Orphaning FreeIPA guide
by Martin Kosek 11 Aug '16

11 Aug '16

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.

5 10

Meeting Minutes - 8 August 2016
by Brian Exelbierd 08 Aug '16

08 Aug '16

We had a small meeting of about 35 minutes post-Flock: Minutes: https://meetbot.fedoraproject.org/fedora-meeting/2016-08-08/docs_project_me… Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting/2016-08-08/docs_project_me… Log: https://meetbot.fedoraproject.org/fedora-meeting/2016-08-08/docs_project_me… Action items randomuser to report on FreeIPA guide situation zoglesby to continue looking at Def Coding Guide shaunm to update on elasticsearch dev env (with randomuser) pbokoc to say gah! pbokoc to clean up beats wiki pages randomuser (and bex can try to help) need to clear the publishing request queue - https://bugzilla.redhat.com/buglist.cgi?component=publishing-requests&list_… grundblom to verify publication of virt-guide and rel notes and if not published open a ticket to appear in https://bugzilla.redhat.com/buglist.cgi?component=publishing-requests&list_… Everyone review the open bugs against guides and close those that are WONTFIX, etc. randomuser to consider rewriting the meeting agenda script to include the new pagure repos regards, bex

1 0

[Fedocal] Reminder meeting : Fedora Docs Weekly Meeting
by Pete Travis 07 Aug '16

07 Aug '16

Dear all, You are kindly invited to the meeting: Fedora Docs Weekly Meeting on 2016-08-08 from 14:00:00 to 15:00:00 UTC At fedora-meeting(a)irc.freenode.net The meeting will be about: An hour of docs folks talking about what they are working on and what they'd like to work on. More information available at: [https://fedoraproject.org/wiki/Docs_Project_meetings](https://fedoraproject… Source: https://apps.fedoraproject.org/calendar/meeting/371/

1 0

Packaging of pintail
by William Moreno 04 Aug '16

04 Aug '16

Hi I read in the planet about the plan of move from publican/docbook to other tool than help made easier to contribute with docs team. Part ot the plan is the packaging of a new tool called pintail. Looks like the original review is stalled: https://bugzilla.redhat.com/show_bug.cgi?id=1334112 So I want to take care of this packaging in this new bug: https://bugzilla.redhat.com/show_bug.cgi?id=1364194 I have a lot sperience with python packaging, please tell who should be commantainers of this package and also a reviewer is welcome. -- William Moreno Reyes http://about.me/williamjmorenor

1 0

[Bug 1361846] New: Typos & Reformulations needed
by Red Hat Bugzilla 04 Aug '16

04 Aug '16

https://bugzilla.redhat.com/show_bug.cgi?id=1361846 Bug ID: 1361846 Summary: Typos & Reformulations needed Product: Fedora Documentation Version: devel Component: virtualization-getting-started-guide Assignee: dayleparker(a)redhat.com Reporter: bughunt(a)gluino.name QA Contact: docs-qa(a)lists.fedoraproject.org CC: dayleparker(a)redhat.com, docs(a)lists.fedoraproject.org Description of problem: ======================= https://docs.fedoraproject.org/en-US/Fedora/23/html/Virtualization_Getting_… contains this text: "The management tools can be located on separate physical machines from the host using secure protocols. libvirt is the the foundation of the Gnome application: gnome-boxes is built apon. " This probably needs reformulation. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

docs August 2016