Personally I dislike pages that fragment and hide the information I'm
looking for behind some high-latency switch-tab / middle-click /
re-load-page stuff. They also tend to make it much harder to search
within that category quickly (ctrl-F style), now I have to do
ctrl-F/alt-N/switch-tab/ctrl-F/alt-N/alt-N/switch-tab/ctrl-F etc. etc.
I agree the information is not as cleanly structured as it could be;
and that perhaps a separate index to the same data might be good (though
it might also have maintenance problems). Possibly just re-structuring
that page would help.
> It is. Anyone vetoing Nunos great work? Opinions?
> (I am hoping for a lot of +1s here for your effort.)
IMHO the discuss list is the wrong venue for any number of +1s when it
comes to developer focused marketing / infrastructure.
I'm also fairly convinced that at a first approximation sorting by
easy-ness is what people most want when they hit that thing; rather than
by more vague categories. Then again - if we have -enough- tasks in each
of the categories perhaps it could be made to fly, but ... needs
I'd also like to hear from some of our new developers that liked that
page - again, on the dev list.
On Tue, Mar 29, 2011 at 4:04 PM, Michael Meeks <[hidden email]> wrote:
> I'd also like to hear from some of our new developers that liked that
> page - again, on the dev list.
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
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.
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.
That way the main page still give a global overview of all easy-hack,
but become much more readable...
If the task are limited, on the main page to a one-liner, then the ToC
doesn't have to be 3 pages long....
> On Tue, 2011-03-29 at 22:51 +0200, Bjoern Michaelsen wrote:
>> Hi Nuno,
> First - great work :-) and good to have you helping out here Nuno.
> Second - this is a page of incredible importance to developers, and as
> such - any changes to it need to be discussed and decided on the
> developer list.
> Thirdly - I'd like to see it changed only after more thought, and I am
> out tomorrow so can't be involved in that.
I'll try to keep the split draft up-to-date, while playing around with
All in this "sandbox", of course. I agree this should only be changed if
people agree, and after being sure it is actually better this way.
>> > I made an attempt to split it under my user pages,
>> > http://wiki.documentfoundation.org/User:Njsg/EasyHacksIndex >>
>> Looking great IMHO!
> Personally I dislike pages that fragment and hide the information I'm
> looking for behind some high-latency switch-tab / middle-click /
> re-load-page stuff. They also tend to make it much harder to search
> within that category quickly (ctrl-F style), now I have to do
> ctrl-F/alt-N/switch-tab/ctrl-F/alt-N/alt-N/switch-tab/ctrl-F etc. etc.
It is harder. I dislike these too :-).
> I agree the information is not as cleanly structured as it could be;
> and that perhaps a separate index to the same data might be good (though
> it might also have maintenance problems). Possibly just re-structuring
> that page would help.
This is split into several pages, but it is possible to join it again in
a single list, after all the subpages are just parts of a big list. It
is a restructuring that happened to involve splitting.
Also, maybe it is possible to have /both/ split-lists and single-list
(But the headings from the split lists are messing the full list page,
The list is big, thus the idea of splitting. But, as you say,
re-structuring will probably help too. Either I misclassified many hacks
as "cleanup", or there are many of them, making the cleanup hacks list
harder to read in the same way the original list is:
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:
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.
(*) One should find a consensus on a good set of tasks early on though.
On 2011-03-31 at 13:35 +0200, Bjoern Michaelsen wrote:
> 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.
Well - I myself am not personally attached to the Easy Hacks I added [I
do it mostly in the shoot-and-forget mode when I spot something
interesting], so I'd support the stand that removing without
confirmation is just OK if on the mailing list, there is an agreement to
do that :-)
Am 29.03.2011 23:24, schrieb Norbert Thiebaud:
> On Tue, Mar 29, 2011 at 4:04 PM, Michael Meeks <[hidden email]> wrote:
>> I'd also like to hear from some of our new developers that liked that
>> page - again, on the dev list.
> 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.
just a question: Is there a database in the wiki? in this case we could
build a table with the necessary variables and display the tasks by
selection of skills and difficulty?
>> just a question: Is there a database in the wiki? in this case we
>> could build a table with the necessary variables and display the
>> tasks by selection of skills and difficulty?
> We already have a database for tasks and that is bugsie.
> http://www.mediawiki.org/wiki/Extension:Bugzilla_Reports >
> might be interesting though.
does this mean we will post our easy-hacks as bugs to bugzilla to get
the wished list?
> Am 01.04.2011 15:14, schrieb Bjoern Michaelsen:
> >> just a question: Is there a database in the wiki? in this case we
> >> could build a table with the necessary variables and display the
> >> tasks by selection of skills and difficulty?
> > We already have a database for tasks and that is bugsie.
> > This:
> > http://www.mediawiki.org/wiki/Extension:Bugzilla_Reports > >
> > might be interesting though.
> does this mean we will post our easy-hacks as bugs to bugzilla to get
> the wished list?
> sorry but my English isn't the best.
IMHO, in general, everyone should file their bugs on bugzilla. The
decision if something is an EasyHack should be done by a developer
however IMHO, as some things might seem easy, but really arent. If you
are not a developer and feel an issue might qualify, you can ask a dev
to have a look at it.
But also keep in mind that there is no pressing need to have all bugs
that are EasyHacks marked as such. As long as we always have >50 open
EasyHacks having more doesnt really help, and even asking devs to check
if a bug qualifies is binding resources. If a dev has some task that he
does not find the time to solve, but know to be an easyhack he should
of cause open the bug directly as an easyhack to avoid additional work.
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
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 :-)
* 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
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
* 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
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
+ 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.
+ 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.