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

[Michael Meeks]

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 at novell.com  <><, Pseudo Engineer, itinerant idiot