Skip to content

Fedora wiki discussion list

21-Oct-08

At the wise prodding of Nigel, we created fedora-wiki@lists.fedoraproject.org.

“Oh, dude,” you might say, “Why another freaking list?” Maybe you wonder why fedora-docs-list isn’t good enough, since Fedora Docs are the wiki gardeners?

The scope of fedora-wiki@ is to be a moderate-level discussion list for everyone who edits the wiki. On the one hand, we prefer and encourage per-page discussions to exist in the page’s Talk: space via the ‘discussion’ tab. This keeps the discussion about the content closest to the actual content, a great model from Wikipedia. At the same time, there is a higher level of collaboration and discussion that the Fedora Project needs around the wiki. The fedora-wiki@ list is where you can get help in using the wiki tools. We’ll be discussing feature requests, change ideas, and announcing new features, tricks, and other things wiki-tool focused. (Note that with some projects using the wiki in Trac, we need to welcome that as on-topic.)

The Fedora Docs list is a meta list that discusses documentation across the whole project. Fedora Docs serves as the upstream for our content style guide, so when fedora-wiki@ has questions and disagreements about writing style, it is Fedora Docs that is accountable for a response. Currently Fedora Docs is also responsible for the wiki editing help and wiki structure rules. Yet, the discussions on fedora-docs-list@ are not all relevant to the wiki-interested audience, and vice-versa. The Docs team needs to have all wiki-relevant discussions on the new list, so the widest audience of users and contributors is involved in real time.

Summary:

Filed in Fedora, Wiki | | Comments Off

Your release notes are looking … thin

06-Oct-08

FREEZE
:: Release notes content is freezing on the wiki for the Fedora 10 Preview Release on 08 October at 23:59 UTC. ::
FREEZE

If you take a look at the wiki pages that are the source for the release notes (Docs/Beats), note the list of content areas (beats) that remain unassigned. What’s going on there? Why hasn’t the Docs Project assigned someone?

FLASH
:: If you don’t assign someone from your sub-project or SIG to cover that content, that area will be empty for the Fedora 10 Preview and possibly final releases. ::
FLASH

Yep, it’s our job to remind you, edit, convert, get translated, package, and deliver. But only you can fill in the content that is missing. One thing we will do for you is hunt through your feature page and pull in any release notes content that you put there. But you have to put it there first, we cannot divine it.

There are also some beats that are assigned but no content has been inserted. Here is your chance (about 2.25 days worth from the moment of this writing.)

Here is a list of unassigned beats that are in danger of being dropped for the Preview Release, meaning zero content appears:

  • Live media
  • Kernel
  • Package notes (misc. package changes) — possibly deprecated
  • Printing
  • Mail servers
  • Developer features (not tools) — i.e., not Haskell, NetBeans, etc.
  • Eclipse
  • Java
  • Samba
  • System daemons
  • Multimedia
  • Entertainment
  • Networking
  • Database servers
  • Backwards compatibility — catch-all for backwards compat notes that don’t fit elsewhere
Filed in Documentation, Fedora | | Comments (1) »

How is licensing fun?

23-Sep-08

Because Spot in looking out for it. Aside from doing a fantastic job, he is brutally honest. He also has a great turn of phrase:

“There’s probably a Perl script running that company now …”

(No, I won’t say what company.)

Thanks Spot for always being way out front on legal and licensing issues. Fedora is freer because of your efforts. You’ve helped all of us be better leaders in bringing free software everywhere.

A Spot avatar

A Spot avatar

Filed in Fedora, FLOSS, Freedom, Leadership, Open Source | | Comments Off

Chickens + feed = eggs

22-Sep-08

Just an anniversary note, we found the first eggs from our chickens on Sunday 21 September. Just in time to celebrate the equinox.  They are right on (one of the) schedules.

So far, it is the Aruacanas who are laying the most, with multiple large, green shelled eggs. When everyone slows down from feasting on first eggs, we get some pictures to post.

Filed in Sustainable Living, Urban Farm | | Comments Off

Relate to this!

22-Sep-08

Not like I plot out my career. For real. I follow my instincts, heart, and then my head, so I’m less good at metrics and more good at, “It feels right.” The goal is similar, though — find a good spot where I can generate the most value for the shareholders, make the most difference for the community, and feel the best about what I’m doing. Happy to say, “Eureka!”

Sometime in the last few shady months, I moved over to the Community Architecture team full-time. Rather than reaching across and through organizational lines to do community work in my ‘spare time,’ after all these years of dreaming of the “full time Fedora Docs lifestyle!”, I am going to attempt a highly public having-my-cake-and-eating-it-too. I’ll shift my title to something fancy and industry-standard, such as “Senior Community Relations Manager,” I’ll continue to keep my focus on all things developer, and jam it all together with the stuff I do right now in Fedora plus whatever the future brings. All just more solidly from the two-hats position of Comm Arch.

My career at Red Hat has been an evolving one, literally metamorphic, changing from one role in to another, from a shadowy association with our community to a solid presence sifting idea packets and cracking project names. From professional services consultant to Engineering tech writer, on to developer relations (ogg) and developer content editor. I enjoy taking on challenging new projects, and it seems our community interaction is a non-stop … challenging … new thing … one right after the other.

It’s unclear if others who have moved to full-time Fedora-slash-community roles are thoroughly satisfied by it. After all, what is thorough? But those are some rather big steps already made, made in the full eyes of the public, and I can’t help but be wickedly nervous.

Here I go to put all my goals up on the wiki. 🙂

Filed in Fedora, Leadership, Red Hat | | Comments (3) »

Your assignment for the upcoming F10 Beta relnotes

17-Sep-08

As Paul so kindly reminds us, Beta is a bigger attention point for a Fedora release. The release notes are front and center in that.

Talk about, write in your blog, share on #fedora-devel and fedora-devel-list, scrawl this URL on the wall of the T station on your way to Harvard Square:

http://fedoraproject.org/wiki/Releases/10/Beta/ReleaseNotes

What do you want to see tested in the Beta?

What should get REALLY BIG ATTENTION?

What will everyone on the fedoraforum.org F10 Beta forum wish you had put in the release notes?

This week we’ll do our Docs part of merging changes and new content from the features pages in to the Beta release notes. Other than pure dumb luck, that’s our best way of knowing what is going on for a release.

Filed in Documentation, Fedora | | Comments (1) »

Formula for making distance work

16-Sep-08

Because I have to miss the North American Fedora Ambassadors Day, I’m thinking (as usual!) about the challenges of remotely working with people. Once again, here is a stellar opportunity to figure out how to include the non-there-in-person parts of the community. Especially around planning and decision sessions, which are different from the what a good portion of e.g. FUDCon unconference sessions are.

The main formula is intent + work.

You have to intend to include people who are at a distance and connecting via technology, and you have to do the work to make it happen.

Call to action for this post is: intend to be highly interactive during the FAD and go make it happen. Hint: blogging is not good enough for some of it.

Think about your sessions and how it can help to interact with the rest of us. I recommend a minimum of: live video feed, live audio feed, and IRC, Gobby, and wiki editing projected on the wall. We can also keep a VoIP conference room open, but my instinct is to limit the flow on the incoming voices by subject matter. Beyond that recommendation, a live IRC and wiki-based abd/or Gobby note taking with many laptops in the in-person session is the bare bones, with regular usage of talk.fedoraproject.org.

I’ve been a telecommuting employee for the last eight years, seven of them @redhat.com. It is not always easy nor comfortable. Success begins and ends with proper intent and hard work. Because NA Ambassador activities are close to my interest, I’m going to do what I can to be involved in the Ambassador Day … from afar.

Filed in Events, Fedora, Online life, Telecommuting | | Comments Off

Wiki structure and naming decisions

06-Sep-08

After moving to the new MediaWiki, it quickly became obvious that the old, CamelCase naming and organization scheme was insufficient. It did not take advantage of the more powerful MediaWiki categorization and namespace capability, created page names that are hard to understand and translate, and pages in CamelCase are (ironically) not searched properly by MediaWiki. In other words, the search does not find “USB” in the title “FedoraLive/USBHowTo” by default.

After many discussions, back and forth decisions, and more time than we really wanted to spend, the Fedora Docs team has ratified a structure and page naming scheme that resolves the above problems.

https://fedoraproject.org/wiki/Help:Wiki_structure

If you have comments on how to improve that document, please use the discussion link instead of changing it directly. This is a policy page and changes need to be approved by Fedora Docs, ultimately.

If you are interested in understanding why we chose these rules and guidelines, you can comment on this post, send us email on fedora-docs-list, or just complain loudly in the usual places and I’m sure we’ll hear about it.

Filed in Fedora, Wiki | | Comments Off

Fedora CMS focus and scope

19-Aug-08

After my post, Why and where Fedora needs a CMS solution, which included a follow-up discussion on fedora-websites-list, there were questions and gentle dissent. I think those stemmed mainly from it not being clear what the intended scope is for a CMS solution. There were also calls for one or another specific CMS solution, which we’ll get to in due time.

One concern expressed in comments to my post were two interrelated ideas: that contributors were going to be forced to use a CMS instead of whatever solution they prefer (i.e., a wiki), and that this would end-up splitting content into different areas, which is confusing for everyone.

The scope of the CMS solution that I am looking for is to cover two specific websites: www.fedoraproject.org and docs.fedoraproject.org. The ‘www..’ site hosts content that is relatively static, usually only changes between releases, and is part of a management and translation process. The ‘docs…’ site hosts full-length documentation that has been drafted, edited, translated, and organized into topics and by version/release. The wiki continues to be a community documentation site, focusing on content of the smaller and easier to digest size and scope that works best in a wiki format, with two audiences: contributors and end-users, in that order.

In addition, there are some specific content topics that have lived on the wiki as their canonical home, which has required them to have an access control list (ACL) defining who can edit. My goal is to get that content’s canonical home moved to the CMS within the www container.

People who work on that more controlled content as writers and editors do not need to switch from the wiki as their preferred authoring tool. It is the formal publishing location that we need to change to be within the CMS. Then we can use the CMS’s native access control tools. This process matches what we do for the release notes, where the community writes and edits content in the release notes beats, but the final publication locations (docs.fedoraproject.org and the fedora-release-notes package) are not wide-open for at-will changes by anyone in the community.

This follows a policy that Fedora Documentation has long used, which Fedora Websites began to follow a few releases ago. For multiple reasons, certain types of content cannot have the wiki as their canonical reference point. One case is where the content integrity is highly important to the very existence of the project, such as legal matters and packaging directions. Content is so powerful in this area that the changing of even one word can put the entire project in jeopardy.

Anther case is when the translations and the original must be in tight synchronization, which is not trivial in a free moving wiki environment. The case that started it all off for the Websites and Infrastructure team was the fundamental slowness of any dynamic content system when the pages are being hammered for information after a release.

(Note to self: the CMS solution must be able to make specific pages or content areas static, serving them from built web components and not out of the database.)

After the Fedora Websites meeting we just had, there is now a specific task I am working against, and a rough timeline. Please continue to leave comments here, on fedora-websites-list, or directly to me via email.

Filed in Fedora, Freedom, Wiki | | Comments (4) »

Why and where Fedora needs a CMS solution

13-Aug-08

Since I answer these questions regularly, as has been this history of this discussion, I’m hammering it out in one location forevermore.

A wiki is a lovely thing, in its own way and when used properly. It is a community documentation tool, making it very, very easy to collaborate on creating ad hoc or planned out content. It significantly lowers the barriers to documentation and greatly increases the contributors to docs. Yay wikis!

But a wiki is not a CMS, just as wiki formatting is not DocBook or ODF XML. One is a useful, easy collaboration tool. The other is what the big boys wear when they go get muddy in the ball field. The real gear.

What does a CMS do natively that a wiki does not?

  • Makes it easy to add someone to a publish chain with minimal training.
  • Makes it easy to segment and control access to write, edit, publish, and read content.
  • Has a method for expiring content after a period of time or set of conditions has occurred.
  • Can accept any document into the work flow, such as ODF, PDF, HTML, and plain text.
  • Designed around a principle of work flow and user role. This allows for content to move from writer to editor (and back and forth), then to a publisher. This is a simple way of enforcing the basic formal writing paradigm. You want someone to fact and grammar check your work before it is put forward as complete.
    • For content, a CMS fills similar roles that koji and bodhi do for software.
  • Are close enough in spirit and function to a blog that many of the same publishing paradigms can be applied, without being locked in to the limitations of a blog engine solution.

What else is good about a CMS?

  • Look and feel is made really easy to manage. All the sites we put under the CMS can snap in to a common design template.
  • Provides rudimentary to advanced version control. Minimal requirement is to allow roll-back of content. Advanced tools provide full VCS or front for another VCS.
  • Pick the right one, and the robust plug-in community will have many things already done for us.
  • It could have a sweet WYSIWYG editor, so it improves on the typical wiki experience.
  • You can still collaborate on the wiki as an authoring and drafting space, then move the final work as snapshots in to the CMS. This is akin to what we do for the release notes.
  • Should improve a team’s workflow at the reduction of a wider field of input.
    • This is why we use it for a limited kind of content that is produced by a team and made to be more static, which makes it easier to translate.
    • Examples of that are: Legal and licensing content; packaging content; formal documentation such as the Installation Guide and Documentation Guide; target pages written by Marketing for releases; mission statements; and so forth.

Where do we want to use a CMS?

Current examples are:

What do we need to look for in a CMS?

I’m going to go hold that discussion on fedora-websites-list, if you are interested. That’s also a good place to raise concerns and suggestions about which pages should move in to a CMS.

When we get together a working list, there will surely be a deliciously collaborative wiki page to go with it, and I’ll publish another post about it.

Filed in Fedora, Wiki | | Comments (7) »