Task:100Days

The maemo.org 100 Days Action Plan

File:50px-Nuvola apps important yellow.svg.png
  • Please login before making any changes. Thank you.
  • Please keep things on-topic.
  • Hardware requests are entirely out-of-scope and will be removed by community members trying to keep this page focused and on-topic.
  • Software requests which would be trivial for a third party to provide — or are already on the roadmap — are out-of-scope and will be removed by community members trying to keep this page focused and on-topic.
  • Don't put things which aren't feasible in 3 months. For long term suggestions, consider adding them at maemo.org 2010.
  • Discussion of the 100 Days agenda should be held in the discussion page.


Contents

Get the server and bandwidth infrastructure up to speed

  • Mirror the repository.maemo.org to ensure good uptime and fast response.
  • Mirror tablets-dev.nokia.com to ensure good uptime and fast response.
  • Improve the hardware and bandwidth availability behind *.maemo.org to ensure good uptime and fast response—maemo.org is too slow!

Increase Openness

  • Identify all closed components in ITOS at each layer:
    • Initfs/direct hardware access
    • Firmware used by kernel modules
    • Low-level system daemons
    • User-space applications
  • For each package:
    • Outline purpose in a dedicated wiki page
    • Describe rationale for it being closed source
      • Will need some form of mediawiki template for such pages --jaffa 22:26, 29 May 2008 (UTC)
  • Document in wiki the process for petitioning for opening of a component, or its specification.
  • Document in wiki the process for ensuring any new closed packages get a wiki page containing this information.

Software distribution

The website

  • Implement some sort of automated single-click push-to-Downloads for Garage projects.

Internet Tablet Talk Syndication

  • Provide an automatic way to syndicate applications to the Internet Tablet Talk Software Section (itTSS).
  • Each application (version) that is syndicated on Internet Tablet Talk, starts a new thread in the forums so end-users get notified of new apps as well as provide a way to give feedback to the developers. Developers themselves can also join in the discussion. This, hopefully, will help to better the quality of applications.
  • Provide a way for developers to easily add a bug at the application's Garage page for confirmed bugs reported in the discussion thread.

maemo "Application Store"

  • Actively hunt on the Net for maemo apps not yet added to Maemo Extras, talk to developers, ask and help them to commit applications to Maemo Extras. This especially applies to app porters currently active at iTT.
  • Use gronmayer's scripts to create a web site that merges applications from all known repositories into a single list and lets you browse them with MicroB using HTML UI similar to N-Gage, Apple Store, etc. While it sounds ambitious, it is not difficult to do, as we always have app descriptions and icons (form .deb files) and we also have screenshots for apps hosted at Garage. Reformatting this data in a format that can be nicely presented in tablet browser is not difficult.
  • Effectively replace "itTSS" with this website.

The repositories

  • Again, because this can't be stressed enough, get the infrastructure behind the repositories up to speed—we need servers, we need bandwidth and we need mirrors.
  • Streamline the acceptance system for Extras(-devel), (not necessarily easier or less stringent, but more straightforward and clear).
  • Lay out the groundwork for a peer-review system for Extras acceptance (or devel to Extras promotion) to help ensue good quality assurance on its packages.

Developer documentation

Clean out the cobwebs, remove the cruft

  • Get what's still useful and mostly relevant completely up to speed for maemo 4.x.
  • Archive the outdated information away from the maemo 4.x stuff.
  • Mark the outdated stuff clearly.

Get organized

  • Put together an easy-to-navigate, sensible index for the documentation content.
    • Place references/howtos/tutorials onto one page so that developer does not need to click through several menus.
  • Improve the search (google?).

Get focused

  • Add porting FAQ wiki page detailing common problems developers will run into (i.e. application is killed 3 seconds after launch) and how to deal with them. Provide examples of typical GTK/Motif/etc. application changes needed to properly Hildonize the application. List ways to deal with porting of toolkit-specific functionality whether it be internationalization or mouse/keyboard input.
  • Make it possible for logged-in developers to annotate any place in the documentation. Link to annotations from documentation.
  • Provide an example of simple build environment *not* relying on AutoConf and its friends. A single includable makefile should suffice, when used with SB2.
  • Clearly *say* in the SB readme that it is not possible to debug every application on the desktop, show how to test applications on the target device using SSH/SCP or some other means.
  • Clearly define what changes is made by default on gtk : like GtkTreeView with hidden header columns by default, or image-button off ...

Look towards the future

  • Define types of applications that will be useful on the Internet Tablet
  • Stress the fact that the Internet Tablet is not a PC and apps should be created/ported with the tablet form in mind. Don't just do a direct port of an existing app. Aim for quality and Internet Tablet usability.
  • Focused discussion/guide on User Interface so apps will have a consistent look as well as provide a similar way to interface with the user
  • Maybe provide a few simple stylesheets and JavaScript libs for creating quick iPhone-like web apps running in MicroB. This should be very light, very easy to use, and targeted to casual users.

maemo.org

Beautification

  • Maemo.org can benefit from some face lifting - right now on 1280x1024 (this resolution seems to be very common to developers) only half of the real screen estate is used. With some loose block positioning both 800x480 and bigger resolutions can be supported. Maybe even specialized tablet finger-friendly look for those preferring it.
    • Resolution seems fine to me at the moment, and it works fine on the tablet without requiring the extra effort of maintaining a separate tablet style. Perhaps reducing the min-width to not require horizontal scrolling with the tablet browser windowed would be useful, though. generalantilles 21:02, 29 May 2008 (UTC)
      • There won't be any extra effort on the resolution maintainment - this can be done with minor CSS modifications. As for the separate tablet style - this really requires extra effort and if done should be entirely optional. bundyo 21:26, 29 May 2008 (UTC)
  • More relevant information displayed on front page, preferably customizable blocks like Netvibes and iGoogle. Since the content is gzipped, that won't be too harming to the traffic. Blocks can be optionally auto updated for those that like to keep their browser pages open (and if Prizm is ported - even in the tray). For instance, a "new bugs" section with voting on the fly will boost bugzilla usage.
  • Make links more standardized. New users often expect links would be underlined, even subtly, or appear to be a button of some kind. Don't rely on hover effects because the tablet can't practically use them. See Wikipedia on 'Mystery Meat Navigation'

Unification of format and style

  • Format and style need to be unified across as much of the site as possible (excluding things like Garage and Bugzilla). Take, for instance Planet and News, two pages that should be very similar, if not the same. Perhaps take News' style and format and apply it to Planet (add the contributor's avatar to the upper right of each article? Much like slashdot does with their article category images.), as the News style seems to offer a cleaner look that better utilizes the available space.
  • For the outliers like Garage and Bugzilla, at least the style should largely be unified with the main site—using the same fonts, same colors, etc.

Update developer libraries

  • gcc-4.x, glib, powervr, it's important to give developers much more time to play with newer tools than short before a major upgrade takes place (of course with disclaimer that nothing is guaranteed to be shipped in a certain way)
  • Update the vmware appliance with sb2 and python2.5 setted. And more publicity on the vmware appliance, as there is already one on garage, but many don't know it.

Focus developers and users on the right channels

  • Today we have too many channels (ITT, maemo.org...). Maybe have some more focus like: maemo.org for developers and ITT for end users and something that links them so software releases can be announced automatically on ITT and users from ITT can easily post bugs on garage bugzilla for example.
    • Perhaps develop a plan, but this isn't specific enough to achieve in 3 months, IMHO --jaffa 22:10, 29 May 2008 (UTC)
  • Develop a recommended usage policy for garage.maemo projects, taking into account turning off GForge modules not needed (perhaps defaulting in a subset rather than all, for new projects). Further discussions on whether non-core bugs should be in central Bugzilla and garage trackers merged/closed.
  • Close misnamed (and now misused) maemo2midgard-discuss mailing list and create maemo-web alongside existing mailing lists for overall discussions about maemo.org sites.
  • It's unclear where to report problems about packages found in the application catalog. A single bug tracker is needed, or at least a catalog that would redirect the user to the appropriate tracker from a common start page. Or we could set up a "maemo" distribution on launchpad.net, which would let us integrate with the bug trackers of individual packages.
  • Single sign on for maemo.org / garage.maemo.org / wiki('s) / bugzilla('s) --> would make community participation easier and the 'karma' calculation (if needed) too

Growing the community through better information for newcomers

  • Currently, maemo.org structure is less than favourable for newcomers to get familiar on what maemo software and maemo.org is. If we want to grow the community we need to provide better introduction to the community and the software assets. Hence, the content of the Intro section should be refreshed and restructured.
  • To create more clarity, I would suggest to remove the "Tips for tablet users" because the link to OS2008 web page is already on the home page. I would furthermore move the "Roadmap" page to the "development" section. The gallery page should be moved to "downloads" and someone should clean up the gallery to contain only relevant content. The presentation section is to some degree outdated and should also be cleaned up. The "White Paper" page should be really give a quick overview of what maemo software is. The "trademark" and "licenses" pages should be moved to "Terms of Use". And the "Links" should be moved to "Development".
  • After all these changes, our intro section should include "Who is the maemo community?, What is the maemo platform? The maemo software architecture, How does maemo.org work? Quick start guide to develop on maemo software, and presentations" --peterschneider 10:02, 30 May 2008 (UTC)
  • The development section should be organized in a simple, clear and centralized way to beginners. The following information is important and should be presented to the newcomers immediately they enter the development section.
  1. Simple steps of getting started should be presented in a clear and definite way ,on a conspicuous area with color. for example:
    1. Sign up a maemo account (link to register page)
    2. Download and set up development environment.(link to detailed method page)
    3. Create hello world application, Package and Test(link to several typical and simple examples,and useful links to advanced docs should be included)
    4. Collaboration on maemo.org and Launch app on the download section (link to pages including usage of project homepage)
  2. Key features of maemo platform should be presented on the section page explicitly.
    1. Free to develop and launch applications.
    2. Powerful enough to create advanced applications.
    3. Flexibility in programming (Gtk+/C,Python,Qt and etc)
    4. Easy to port existing application.
  3. Wiki on frequent technical problems in programming(the how-tos part),and entry to developer's disscusion board(link to ITT's or a new one) to help newcomers to find solutions to difficulty and ask for help.
  4. All docs in a catalog with good classification for look up.
  5. Maemo's roadmap and history, technical news and announcement about maemo.
  6. Maemo app gallery and entry to experienced and recently active developers' tech blogs.
  • Each app launched on maemo.org should contain more screenshots so that the function and UI can be more explicit to new users.
  • Maybe just "maemo 2008" instead of "maemo linux based OS2008" is a more attractive name.And next breakthrough could be "maemo 5". A well-designed emblem associate to it should be under consideration.
Retrieved from "https://wiki.maemo.org/Task:100Days"