[Libreoffice] Easy hacks page re-work / thoughts ...

Hi guys,

        So finally I read the thread, and everyone's comments; and thought it
through a bit more, and there are lots of good things that we can do
here to make things better I think, though ultimately nothing will be
perfect.

        My proposal for fixing things is at the bottom, hopefully it is
something we can all agree on.

        The next question of course is - who would like to resource it / help
get the server piece configured & working, I guess task B. the re-filing
of existing easy hacks into bugzilla  with the first comment being a
~perfect description - needs some real man-power :-)

        Thoughts ?

                Michael.

* Some summary / thoughts:

        It seems we are all agreed (or not disagreed), that this is a very
important page, and we need to get it as usable and friendly as
possible.

        My aim for the page is (essentially) to introduce, and train people -
coaxing them up this "on-ramp" until they become ace feature writers,
(and ace hackers with it :-).

        My skepticism of categorisation is that it can lead to failure there:
with people getting stuck in an endless "code cleanup" phase.

        So - personally I feel that Bjoern's suggestion of having a small
selection of taster tasks on the front page across all areas is best,
under 50 of these would be good, prolly better around 20 or so.

        Of course, the ability to sort by easiness, language-choice etc. would
be great, as Norbert points out, mostly a one-line description is enough
for people.

* Pros & cons wiki vs. bugzilla

        At least, as I thought I had these pros and cons in mind; certainly
there are more I forgot :-)

        * Pros of (huge) flat wiki page
                + trivial to search
        * Cons of (huge) flat wiki page
                + hard to edit
                + hard to sort and navigate when big

        * Pros of bugzilla:
                + user account may be more useful than a wiki account
                + query-able, possible to give several views of the data
                  "Perl easy hacks", "sort by difficulty" etc.
                + gives an implicit E-mail interaction / notification
                  mechanism for each task with a mentor / reviewer
                + better history & logging - we can see who added a bug.
        * Cons of bugzilla
                + bugs are append-only (ie. hard to edit), and plain-text
                + reading a bug is extremely unpleasant - it starts
                  with a whole page of irrelevant crud: "additonal
                  comments" box, and tons of annotation combos / etc.
                        + you have to work hard to read bugs.
                + search-ability, bugzilla's search is slow, unpleasant
                  and yields a result that is again horribly hard to
                  read and unpleasant to use (cf. previous point).
                + latency - loading a new bug in bugzilla has a high
                  latency, of the order of the time it takes to load
                  the entire 'Easy Hacks' page now.
                + higher latency / server load the more queries we have

* Bugzilla concerns

        * We need to ensure that random people are not just marking bugs with
          EasyHack status just to get them looked at by someone (a real risk).
          An Easy Hack by definition has code pointers to make it easy:
          bad:  https://bugs.freedesktop.org/show_bug.cgi?id=32506
          good: https://bugs.freedesktop.org/show_bug.cgi?id=31609

* Suggested transition plan

        A. get http://www.mediawiki.org/wiki/Extension:Bugzilla_Reports setup
                + get mouse-over-hover to render the -first- comment
                  as prettily as possible - hopefully a well formed
                  task description we got right 1st time.
                + verify that page loading time is not substantially
                  impacted - the page must be quick to serve, presumably
                  not using 'disablecache' will help this.
        B. duplicate existing easy-hacks into bugzilla, and link
          them back.
                + work out & document in the wiki a std. schema for
                  'easiness' and whiteboard tags for other attributes:
                  UI vs. cleanup vs. performance, perl vs. python vs.
                  javascript vs. C++ etc. (?)
                + IMHO having something we can "sort by" for easiness,
                  'severity' perhaps (?) would be rather key.
        C. stick with a single wiki page:
                + continue to sort by difficulty
                + pull out some (under 50) representative
                  'easy hacks' and have them mentioned in-line
                + embed the Bugzilla_Report for that category
                  after that ?
                + add per "category" bugzilla-reports at the bottom:
                        + "UI", "Performance", "Cleanup" etc.

        I guess A. and B. can be done in parallel, and lead to C.

-- 
 michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot