Skip to main content

KDE - Authors //Promoting book writing in KDE


If you are in any way related to KDE even if you are just a user and think you can/want to help/join us then without giving a second thought fire an email to me. (supreetpal@gmail.com)





How it all began . .



Last October, Google invited proposals for a GSOC Doc Camp Sprint. The sprint was organised at their offices in Mountain View, California and luckily a team of KDE-Contributors got their proposal selected (I was one of them). Over there, we were teamed up with independent volunteers who were basically professional editors and were briefed about the whole plan. The layout was simple, we had to spend the first few hours outlining the chapters and target audience for our book, then spend the rest of the sprint working on the content. We had proposed to work on a beginner’s guide to KDE development, for developers. Most of the content required by us was available on the wiki but writing a book is a totally different approach than writing a wiki. Working 12+ hours a day , things were on warp drive but what we accomplished made it totally worth the effort. By the end of the sprint, the first edition of the “ Beginner’s Guide to KDE Development” was ready.

Read the Dot article. [1]


So now what?


At the sprint, we were introduced to booki on flossmanuals [2]. It is an online tool which is developed to be used for cooperative book authoring over the internet. Since the time I was introduced to it and finished up the beginner's guide [3] [4], I was really amazed by level of convenience and speed with which we could actually have a full book ready, working together over the web. Our team had discussed various ways and ideas through which we could exploit this tool and how we would drive a small community of enthusiastic (not necessarily professional) writers to maintain the developer’s guide and create new books. Sadly enough, when the sprint ended each of us got back to our routine and busy with the work we had on our hands. Due to limited availability of time with each one of us, we weren't able to drive any work force behind the idea considering the fact that it took us around 3 months to actually get our nearly completed book, out of the closet. Finally, I have been working on this idea for some time so the basic layout has been jotted down below and anyone who likes it, please join us in this endeavor.


The idea . .


What I am proposing is to get together a group of people who are interested in authoring/editing books related to KDE. The name "KDE-Authors" in itself is self-explanatory , that is people who would write, maintain and publish KDE books. You DON'T have to be a professional writer or editor to join us. If you are in any way related to KDE even if you are just a user and think you can/want to help/join us then without giving a second thought fire an email to me. (supreetpal@gmail.com)


Why books?
  • Convenient to carry.
  • Have a bounded nature ( a defined beginning and an end ).
  • Have a better and more engrossing language as opposed to wikis.
  • Available offline.
  • Not dependent on any digital media. ( Digital copy would also be available)


Work and Purpose:
  • Author and publish new KDE books.
  • Update and review changes to existing books.
  • Guide and involve new interested contributors.
  • Publicize and manage the selling and distribution of books.
  • Accept and review calls from KDE developers/users for new books on requested topic/subject.


Use case scenarios:
  • A book for KDE users introducing them to plasma and other KDE software available.
  • A collective book on KDE sprints.
  • A book on KDE community.
  • Updating existing books parallel to development.



Why do we need this at all?


The following is an extract from the FLOSS Manuals blog and I feel it expresses my views very accurately:



“Free software documentation has often been a very low priority for free software projects. Often the documentation suffers from common flaws including:

  • no documentation existing at all
  • assumptions about the user's knowledge are set too high
  • poor navigation
  • unexplained jargon
  • there is no visual component
  • the documentation is proprietary or 'closed'
  • the format is unreadable
  • no translation workflow
  • operational steps are missing, unexplained, written 'from memory' or state how the software 'should' operate
  • the documentation is out of date, not easily re-usable or not easily modifiable.
We hope to shine light on the importance of the free software documentation 'sector' in the ecology of Free software. Free (libre) documentation is not simply an aid for learning how to use free software, it is a road into education and adoption in industry, a tool for demonstrating to clients how free software will meet their needs and expectations, and an important promotional tool for the advancement of free software. A healthy free documentation sector is both socially and economically empowering. We believe Free Documentation of Free Software efforts and ideals should be valued on the same level as free software itself.”


Links above:
  1. http://dot.kde.org/2012/02/05/kde-development-%E2%80%93-beginners-guide
  2. http://www.flossmanuals.net/
  3. http://flossmanuals.net/kde-guide/
  4. http://www.lulu.com/shop/kde-authors/beginning-kde-development/paperback/product-18849700.html;jsessionid=81E5D5381C1F6FB92297C34E002DF8AF

Comments

  1. Join the BoF at Akademy: http://community.kde.org/Akademy/2012/Wednesday

    ReplyDelete

Post a Comment

Popular posts from this blog

Nouveau - Summer Project

Implementing a software scripting engine on Fermi to achieve safe memory re-clocking. Fermi stands for Nvidia GPUs based on Fermi architecture. NVidia cards have long had the possibility to reclock at least some of the engines of its GPUs. Up to the geforce 7 (included), reclocking used to happen at boot time and usually didn't involve memory reclocking at all. It changed with geforce 8 (nv50) where almost all laptops got the capability to reclock both the VRAM and the main engines. This was introduced in order to lower power consumption when the GPU was mostly idle. The default boot clocks were usually in some intermediate state between the slowest and the fastest clocks. The reclocking process for these cards is mostly understood and Nouveau is not far from being safely reclock on the fly, even while gaming. Geforce 200 (nva3) introduced load-based reclocking on all the cards. This started being a real problem because the default boot clocks are a third to a half of the

uCharts - Financial Charting API

A few months back, the first stable release of the charting API, that I have been working on was released. A part of the uTrade product portfolio, it has been aptly named uCharts. uCharts is a general purpose charting API with prime focus on financial markets and data. In this post, I will give a brief overview of the features, compatibility and scope of extensions. Features The API currently supports 6 types of charts: Line Area CandleStick OHLC Bar Pie It has been designed in a manner that all aspects of the charts are user defined. Starting from the color of the charts, width of the candle bars till the number of ticks on each axis. Mentioning each element seems like a futile exercise. However, brushing over a few notable features seems more fruitful. Aggregation Formula The number of data points that can be displayed on a screen or inside a DIV is limited by its resolution. The number of pixels available can lead to a severe limitation especially

Two concepts to help upgrade our definition of science

Two concepts to help upgrade our definition of science.  Everybody agrees that there are a ton of things which people believe in to have some basis in science but don’t. This agreement is however limited to what somebody else believes in and not they themselves. Applying the scientific method to everything that we come across is not possible. We as individuals have neither the resources nor would our experience as a single data point count for anything more than an anecdote. There are two concepts to help us check if what we believe in would even qualify to be evaluated by the scientific method. The first is “correlation does not imply causation”. Just because two things are found to be correlated, it does not mean one is the cause of the other. The more popular version of it is a similar fallacy, an event that followed another was necessarily a consequence of the first event. For example, you bought a car on a Saturday and then later met with an accident. Drawing a conclusion th