[Libreoffice] [tdf-discuss] Re: EasyHack on EasyHacks

[Bjoern Michaelsen]

Hi Norbert,

On Tue, 29 Mar 2011 16:24:16 -0500
Norbert Thiebaud <nthiebaud at gmail.com>
wrote:

> The easy hack page has hugely grown since I started. I guess that is a
> good thing, but in my opinion it's current form is not very practical
> nor inviting.

I think it is also becoming unmaintainable. This can be seen for
example by:

 http://wiki.documentfoundation.org/Development/Easy_Hacks#Get_rid_of_sal_uLong

which we had a lengthy discussion about:

 http://nabble.documentfoundation.org/Purpose-of-easy-task-Get-rid-of-sal-uLong-td2742651.html

where we disagreed over the details, but agreed that the easytask as is
is a bad idea. Why wasnt it removed on the wiki page? Because it is a
huge pain to dig through the history of that huge page to find the
orginial author and politely ask him, because simply removing it is
offense. I added a ON HOLD note to the task btw.

> I think that grouping easy-hack by 'nature' and then by difficulty do
> make sense. Difficulty is a very subjective measure,
> and something that is a 'easy gui hack' for someone may be a daunting
> task for someone else... when I was parsing this
> list I would first look at the title, then the skill required and
> _then_ the degree of difficulty announced - mostly to
> verify my first impression based on the previous 2 items.

Yes, I imaging the average coder foolishly stumbling on that page with
the idea "maybe there is an interesting hack to do". But I also image
the average Joe P. Coder to read only the first 10 bullet points, then
going back to the TOC, scan the titles of the next 20 bullet points an
if he does not find something interesting there, and otherwise find the
next project to see if there is something exciting to do there. He
might just be checking out a set of "candidate projects" to see were he
will spend his time on.

I really dont think most first time readers of the page will read past
the first ten points to get an impression of the project. The rest will
likely only be read by people coming back -- and those already have
other means (ML, IRC, bug tracker).

> So, I do like the 'nature' oriented classification proposed, but maybe
> we could keep a one line overview of each task with a link for a
> dedicated page per task
> That way, a given task can be expended with as much information as
> needed without flooding the main page, including volunteer's progress
> report, declaration of intent and/or questions/answer section to
> clarify the task if need be.

As others have pointed out using one wiki page as a flat database (which
is what we are currently doing) is a bad idea.Some people might search
for an easy hack by "nature", others by difficulty.  Having a deeply
fragmented structure on the wiki is bad to (hard to maintain) as
Michael points out.

Creating a new database and custom tooling is obviously the wrong thing
to do too (and what Sun/Oracle would have done considering EIS, Quaste
and a lot more). There should be one and only one database for the
project. Fortunately, we already have one right here:

 https://bugs.freedesktop.org/

Using whiteboard status "EasyHack" and some more tags to classify stuff
like "nature" and "difficulty" should make that whole thing very
flexible and for the number of items should scale well (or at least
better than > 100 items on one flat page).(*)

The EasyTasks page then should only highlight some selected ten to 20
items and otherwise refer to the relevant queries on bugsie.

Best Regards,

Bjoern

(*) One should find a consensus on a good set of tasks early on though.

-- 
https://launchpad.net/~bjoern-michaelsen