Fedora Community

[Luke Macken]

Excerpts from Stephen John Smoogen's message of Tue Jul 05 17:44:46 -0400 2011:
> No not http://fedoracommunity.org but
> https://admin.fedoraproject.org/community/ It has been in beta for 2
> years now. What do we need to do to finish it (maybe make it
> start.fedoraproject.org?) or put it aside for other things to do?

This app was never really intended to ever be "finished". It was meant
to be a platform for building widgets to visualize Fedora data. However,
I do think it's definitely still 'beta' quality, and the original
authors (J5, Mo, and I), have not had the cycles to continue to improve
it. We accomplished our initial goals, and then got pulled into
different directions (one of which was working on the core of the
platform, Moksha).

Personally, I still use fedoracommunity on a regular basis, and find it
to be extremely useful in many ways. Right now we do not have any idea
as to how many people are using it. I think we should do some log
analysis, and maybe a survey to see what people like/dislike/want. Also,
Mo did a usability study at FUDCon many moons ago, and we have yet to
really sit down and analyze the results.

So, in order to remove the 'beta' from fedoracommunity, I would
personally like the see the following happen:

    * Polish up the interface, and make it *much* snappier.
      Right now the interface feels very clunky, and the full page
      reloads when clicking on certain areas is killing us. There
      is still a lot of low-hanging fruit in terms of optimization.

    * Re-branding, marketing, and a better URL.
      "Fedora Community" has become an overloaded term, and has since been
      associated with the language-specific subcommunity portals. We also
      don't link to the app from anywhere, and the URL is not the
      easiest to remember.

    * Documentation.
      Right now there is no documentation that guides people through
      building a new app/widget using our infrastructure's APIs.
      Copying/pasting existing code has made contributing painful.

With regard to the claims that the AGPL makes this app difficult to
maintain -- I honestly cannot recall a single case where we had to
hotfix it and jump through the AGPL hoops. If anything, this helped us
figure out what it takes to develop, deploy, and maintain both
TurboGears2 and AGPL applications.

Spot, J5 and I will be meeting next Thursday to draft a potential
roadmap going forward.

Personally, I envision the following improvements and additions (as I
mentioned at the last FUDCon):

    * Mailing list interface (a decent amount of code already written)
    * Meeting app, to visualize our meetbot output (some code written)
    * SIG dashboards, with action items, SOPs, packages, people, meetings, etc
    * Package review app
    * Improved upstream integration & adoption
    * Nightly spin analysis
    * Source-level code/diff viewer for auditing/annotations/linking
    * Realtime message broker integration into our existing infrastructure
    * Realtime widgets to visualize these live data streams

luke