This morning the first smile I had was when I looked back over my shoulder at the Boston Cambridge Marriott to see not only my own Fedora window sign, but the signs of many others. (There is a small cluster of folks on the 19th floor.)
The signs are a small brilliancy that came from (I think) the mind of Clint Savage (herlo). It’s a good example of a smaller thing that was relatively easy to execute making a memorable conference experience.
As I walked up to the MIT building with Xavier, we spotted the same signs in the glass stairwell, clearly illuminating the presence of FUDCon
Standing out in a window, the signs are 28 cm (11 in) by 43 cm (17 in), with a blue Fedora logo centered. Clint and whoever helped him applied small pieces of clear double-sided tape to the four corners of the face of the sign. You apply it facing outward to your hotel window. Where it really helps is when you and a group of people are sharing a hotel. We have a large number at this same hotel, I don’t know how many but more than 30 I can reckon from what I’ve seen. The work was all done at a name-brand full-service print-shop.
I’m not sure if there is a page of similar tricks for Ambassadors. Sadly, the Ambassador wiki pages are many with categorization and old-style page naming working against it. At least, my search for ‘ambassador tricks’ turned up nothing. (Hoping some folks who want to learn how to do that effectively come to the wiki talk today.)
So I created these pages, and hope someone else is sparked by Clint’s idea to make a similar impact at one of your events. Don’t forget to share and document your experience:
https://fedoraproject.org/wiki/Tricks_for_Ambassadors_from_Ambassadors
https://fedoraproject.org/wiki/Category:Ambassador_tips_and_tricks
You may have noticed there is a larger world of free software outside of Fedora than inside. The number of packages inside the Fedora Universe has really grown.
You may have noticed there is a larger world of Fedora-specific how-to documentation outside of Fedora than inside. A really huge amount. You may notice that the amount inside has grown very little by comparison.
There is new how-to documentation on the Fedora Planet nearly every day. The Fedora Forum is full of useful (and not so useful) content. Sub-communities such as Fedora-fr have rich document sets. People write how-to content in to their blogs, to their own wikis or CMS systems, or post downloadable content from any number of places. I just caught up on a thread on Fedora Ambassadors list about a Fedora 10 how-to document. As cool as it the document is, as great as the effort is, I could not help my first thought. “Why is this document not written as part of Fedora itself?”
You know, just write it and add [[Category:How to]] and [[Category:Draft documentation]] to the pages.
The irony is, it is harder to get a package in to Fedora than a document, but because of our poor documentation (compared to the Packaging Guidelines) and equally poor marketing(?), not many people are taking the step to bring Fedora content inside of Fedora.
Since there are going to be a large number of contributors handy at the upcoming FUDCon, maybe that’s a chance to talk about it.
There are some very-near-term fixes that are going to make it easier to bring content inside of Fedora. Then all we need is the better marketing. 🙂
- Recent wiki gardening work, including page renaming and smart category usage, is yielding a useful wiki. Ian Weller, myself, and others are going to be swinging the wiki hammer at FUDConF11, and it’s much more than learning about the markup. There are real and useful best practices that yield you a useful set of wiki content. Looked at the Fonts SIG pages lately? That’s one way to do it. Hopefully I’ll be showing off the newly trimmed, renamed, and categorized Docs Project pages at FUDCon.
- Better localization for the wiki — a wiki per native-language means people can include locale-specific content as well as content translated from the main English wiki. What would help more here is a way to track when new pages are created in native-language wikis that do not correspond to one from the English wiki. This flags those pages as possibly worthy of translation to other languages, including English.
- A content management system. I’ve been talking about this for a while, and hope that FUDCon helps move the needle on this activity. This helps by distributing publishing rights to the teams who own the content — the writing teams, the SIGs, and the other sub-projects. By having content more tied to Fedora versions, it make it easier on writers who only want to maintain content for a specific version of Fedora.
- This all makes using DocBook XML much easier for everyone. We’ve already had a boost from the relative ease of using Publican. By hosting each guide as a separate project on fedorahosted.org, the onus and accountability is firmly in the writing team and not blocked by project administrators. This was how we rolled for Fedora 10 in doing the Installation Guide and Release Notes — task tracking with Trac and project management from within the team. When that content is using an installable, upstream maintained system such as Publican surrounded by standard processes, we are much farther in the goal of creating a useful, repeatable documentation process that can be borrowed from Fedora and used in other places.
If you are writing content that really could or should be on the Fedora wiki, please join the wiki mailing list and find out how to do it right.
This is a blatent swipe of my original email to the list. I’m revealing some of the interesting bits we’re going through in the Docs Project in improving our processes using the wiki in smart ways. I’m hoping this is useful for other projects who want to renovate their presence on the Fedora wiki, which serves as the main project face for most contributor groups.
Thinking about our various processes, it seems a good idea to put them in functional areas. A process might be used in one or multiple parts of the project. For example, a process for requesting access to a document on fedorahosted.org is used in many functional areas, such as recruiting, training, writing, editing, and publishing.
How does this list of functional areas look:
- Recruit
- Train
- Gather information
- Write
- Edit
- Publish
- Steer/govern
- Project manage
… what is missing?
My thought from here is to:
- Leave each process page in a master [[Category:Docs Project process]], which happens after wikibot runs from our docsproject.psv choices.
- Add each process page to one or more sub-categories, for example [[Category:Docs Project recruiting process]]. The pattern of “Docs Project something process” is pretty clean and clear. This avoids obscuring acronyms, for example SOP for ‘standard operating procedure’.
We’ll want a master page for each functional area, and it links to each of the other pages used in that process that also happen to be in the same sub-category. The sub-category page is a nice way to see all pages in a process.
This is my thinking so far in how to improve our processes, clean-up the content, and use a MediaWiki-smart approach.
As part of a general housecleaning and reorganization, the Docs Project did some work to bring the Fedora 8 version of the User Guide out of obscurity. Originally destined for conversion to XML (to be translated, etc.), this guide has languished on the wiki in a draft location, unfindable and unloved. No more!
http://fedoraproject.org/wiki/F8_User_Guide
The nice thing is, while the Docs team is done with this guide and won’t do a further thing to it when Fedora 8 community support ends, it still lives on in the wiki.
People who choose to continue using Fedora 8 have the option of maintaining and adding to that content, and of course, we’re here to help them learn about how to write useful content on the wiki. Starting with:
https://fedoraproject.org/wiki/Help:Editing
https://fedoraproject.org/wiki/Docs_Project_Style_Guide
The Fedora Docs team is going to have a series of hackfest days over the coming holiday weeks. Topics being so far include:
- Wiki training – how to, do this, don’t do that, etc.
- Conversion of an existing Fedora Docs guide to Publican
- Finishing of the F9 User Guide, possible conversion to XML
- Start work on the F10 update to the User Guide
- Full revamp of Docs team process and internal how-to documentation
Although taking the form of a hackfest, we are also envisioning this as akin to the recent IRC classroom sessions. If there is something you are interested in there already or want to see a session added, contact us via fedora-docs-list.
Did a little clean-up of the page contents and naming for the independent software vendors (ISV) special interest group (SIG) pages.
https://fedoraproject.org/wiki/ISV_Special_Interest_Group
https://fedoraproject.org/wiki/Category:ISVs
One of the goals I am pouring more personal resources in to is the recruitment and support of ISVs for getting packages in to Fedora. Now that the Fedora 11 schedule is set, we can start getting ISVs to aim for that target. As one example, ISVs are collaborating on finding, using, or maintaining packages for JARs not in Fedora. (If you are interested in helping with ideas around Fedora and JPackage, contact me.)
This came about because I was tired of ‘ISV’ as a search term turning up no real results from Fedora’s MediaWiki. So, as part of this, I setup or fixed redirects so related terminology finds the same location. It’s still a bit disconcerting that ‘isv’ doesn’t turn up a hit in the search; I need to look in to why it is configured in MediaWiki that way.
A few days ago we got a nice view in to all the opinions and methods for dealing with tapping and the touchpad in Fedora 10. Today I did an hour of work getting Jesse’s suggestion working. In the end, the minimal ‘xorg.conf’ file was not enough. I spent some time reading through the xorg.conf(5) manual page but could not resolve the syntax error I got when trying to start X with the minimal details. I ended up copying in the ‘xorg.conf’ I saved/used in Fedora 8 and 9. Not a hack I like, especially since it involved removing the hal files, obviousy a retro-action instead of Doing it the Right Way.
When I get another hour to break things, I’ll try out the comments that suggested working with the ‘.fdi’ file instead of ‘xorg.conf’.
As I should have expected, my post brought out the usual detractors of touchpads, those who I call “Fans of the Dipstick.” As it happens, I really dislike the little thimble/dipstick/pointing stick design. I’ve never been able to get it to drive right — my mouse actions look like a four-year-old trying to get the arrow just right to click on a button. But, hey, to each her own, and all that. I appreciate having both choices on my Thinkpad so I can use the dipstick on the rare occasion I am tweaking the touchpad settings. I just wish there was room to put a middle button below the touchpad, but I’m used to the stretch-n-paste by now.
For me, the touchpad is more intuitive, easier to control, and I really dig the side scrolling. The touchpad provides a wider range of motion and interesting possibilities, such as the gestures. But, hey, that’s just me. Keep on stroking your dipstick and disabling your touchpad in BIOS, it’s all good.
(Below for an appeal on how to disable tapping for the touchpad in Fedora 10, which is now different than previous.)
Upgraded to Fedora 10 on the Thinkpad T60, overall everything is pretty sweet. I tried to upgrade from F8 using Anaconda, the result wasn’t that pretty and left me nervous — I was still cleaning up from the last upgrade done that way, so I decided a fresh start was going to be OK. I have my full package list from before, now I’m just sorting through getting all the same software installed. The long road.
Why is that list 1000 packages long? During install, I got to the package selection screen and had a touchpad FAIL. The screen loaded the “Office and Productivity” default, where I would then normally go through the package groups and lists and add a whole bunch of fun stuff. But when Anaconda advanced to that screen, the mouse arrow was over the ”Next” button, and a click initiated by the touchpad tapping made it advance. Perhaps it was a coincidence that the arrow was over the button, but once you click ”Next” on that screen, there is no going back … even though there is a ”Back” button visible in the next screen.
Faced with abandoning and restarting the install, I figured I’d install and add packages later. Which is turning out to be hours of effort, partially because working with PackageKit and the stupid tap-is-a-click touchpad is such a PITA. I haven’t used the tap-click stuff in so many years and my rough touchpad style is causing lots of mis-clicks.
Since there is no longer an ‘xorg.conf’ file to add the details to make ‘gsynaptics’ work, I haven’t yet found how I am supposed to control touchpad details. I appeal to the wise Web and Fedora planet — any good ideas?
I suppose that if I were to make an ‘xorg.conf’, such as with `system-config-display`, it would work, but that defeats the otherwise stellar Xorg working method. If we get a better solution, I’ll be sure to post on fedoraforum.org about it.
We’ve been working with git as a distributed version control system (DVCS) for Fedora Documentation this release. All of these documents (Installation Guide, Release Note, and various README files) are authored in DocBook XML, so they work great within a VCS.
Sure, it’s cool to work entirely offline, do granular commits, and merge perfectly with the codebase when I’ve reconnected later. That’s all good. What has been a real gift from the gods the last 48 hours is how fast it is. Especially the operations via the network; I see very little bandwidth used and it goes by very quickly. No more ‘cvs ci’ and wait.
Another great aspect is how a DVCS such as git supports a distributed team working in real and non-real time. Unlike with old VCS, it is much easier to work divergently and still have it merge together. For example, after I do a number of changes, I make granular commits, which occur only in my local repo (clone.) I can do a commit per file, so I have a specific changelog tied to the actions, and it is easier to undo or manipulate from that commit, which has it’s own UUID. Then I only have to run ‘git-pull –rebase’, which pulls down any changes pushed by other collaborators, updates my local repo, and replays my changes on top of this new copy of HEAD. Then I can ‘git push’ without any conflicts arising.
In a VCS, if you find yourself out of sync with the latest from HEAD, you either have to sync and deal with potentially spurious merge errors, or do a manual version of what git does. How many times have you copied your changes from out of a Subversion or CVS directory locally, reverted back to HEAD from the central repository, then manually reapplied your changes?
If anyone is making them … I want a t-shirt that says “praise git”.
With people writing about running for the Fedora Project Board, I want to take the chance to say I am not running for election this time.
My Red Hat-appointed seat of the last 18 months expires with this election. My interest is in seeing some new blood working on the Board. I haven’t been spending as much time directly on Board projects in the last six months, which is a good argument for new blood :), but also comes from the crossover of my work in Community Architecture. I’m a 100% community guy all the time now, so the board is only another 1% on top. By bringing in new people, there should be a surge of new ideas and energy. Especially with the caliber of people such as Dimitris and Michael.
Which is the other reason I am not running. Red Hat is going to want to appoint someone new to my seat rather than extend my stay, and that is definitely the right thing to do. To stay on the Board, I have to stand for election for the first time. No problem there, I think I’d have a fair chance, but then I’d be blocking one of these other great community organizers to have a chance leading this ship.
What I’m looking forward to is running in the next election in six months, when the new round of people are more seasoned and have had a chance to steer the Board for a while. I’ll be refreshed, full of new ideas, and ready to engage. If I should be fortunate enough to get elected. 🙂