Fedora 25 Alpha Release Readiness Meeting, Thursday, August 18 @
19:00 UTC
by Jan Kurik
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
7 years, 8 months
Re : Translation needs clarity on how to get updates published and the process.
by Jean-Baptiste
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.
7 years, 8 months
How do we move to topic-based writing? Is there a plan?
by Brian Exelbierd
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
7 years, 8 months
Re: Should we stop publishing the current guides now?
by Pete Travis
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
7 years, 8 months
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, 8 months
[Bug 1361846] New: Typos & Reformulations needed
by Red Hat Bugzilla
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_Gettin...
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.
7 years, 8 months
