incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: Looking to get involved
Date Wed, 04 Apr 2012 17:07:56 GMT
On Wed, Apr 4, 2012 at 8:25 AM, Ian <ian@amham.net> wrote:

> Hi People,
>
> not sure if this is the correct place to raise my head, but I have been
> lurking here for a week or so now with a view to getting involved. Like
> everyone I am not sure how much time I really have.
>
>

Hi Ian,

Welcome to the project.  Although "ooo-dev" might sound like it is only for
developers, it actually is the project's main list.  So you are in the
right place.

We have some subsidiary lists as well:

http://incubator.apache.org/openofficeorg/mailing-lists.html



> My background is that of a software developer for some twenty plus years
> (currently employed by the same institution as Rob, but on the other side
> of the world, in Australia).
> I'll skip the resume etc. I figure people are more interested in getting
> things done.
>
> I have been looking around at the get involved links. They are very
> misleading and take you to places that look like they have not been updated
> for many years.
> like ,,, http://codesnippets.services.openoffice.org/index.xml which is
> from the http://www.openoffice.org/development/ page. I'm sure I saw
> cobwebs in the corners there.
> (A review of the potential new developers interface may be needed?)
>
> Anyway, I'm sure I will find my way around eventually. All guidance
> gratefully accepted.
>
>
Hmmm.... This should be our main "get involved" page:

http://incubator.apache.org/openofficeorg/get-involved.html

But it sounds like there are paths that lead visitors elsewhere.  We need
to fix that.


> I don't understand what if anything someone needs to do to join the gang.
> Are there any weird initiations, gotta get the new logo tatoo? :-)
>
>
If you contact me via Notes, I can fill you in on the internal IBM
requirements (Open Source Participation Guidelines).

Also, take a tool at the Apache roles and the way the meritocracy works:

http://www.apache.org/foundation/how-it-works.html#roles

No paperwork is needed for contributers.  There is an iCLA form that you
can sign and return.  Even though it is only required for Committers,
anyone who thinks they will be active in the project is encouraged to
complete that paperwork.

I am particularly interested in developer testing frameworks (still trying
> to figure out why).
> And langauge parsers/compilers.
>
> I am also a new Master's student (must have lost my mind somewhere) and
> wondered if I could combine helping here and also using some of the
> knowledge gained as part of my thesis.
> Not sure what the rules are re IP etc.
>
>
There are some interesting things that could have research interest as well
as helping the project.  For example, consider testing document layout.  We
can automate document creation, and specify the styles and content of a
document, but verifying whether it appears correctly is a manual task.

At the simplest level we might want to check to see whether today's build
renders documents the same they were rendered in the last release.  So we
want to detect regressions.

At a more complex level we might want to verify correctness of the
rendering, as defined by some specification.

Having high quality rendering in this area is of critical importance to
users, but today is a manual task.

Now you could imagine just doing screen shots and doing pixel level
comparisons.  That is easy to implement but will be overly-sensitive and
give many false positives.  Slight UI changes, platform differences, etc.
can introduce insignificant changes.  Some of augmented this approach by
looking at the percentage difference in the before and after images.

Another approach might be based on OCR technology to deconstruct the
rendered document to determine facts such as size of margin, number of
lines of text, alignment, size of headers, etc.  These facts could then be
compared to a test specification.  This approach might be easier if the
document is first rendered to a PDF file rather than using a screenshot.

And another approach could be to rely on human judgment on sameness or
correctness of the rendered pages, but devise some way to crowd-source
these comparisons.  For example, we could have a web-service that would
show the before and after images, a different one each time, and ask users
to mark them as same/different/not sure.  Or give the specification for
what it should look like and ask viewer to score them.

An example of that technique can be seen at "Galaxy Zoo" where astronomers
use crowd sourcing to classify galaxies:

http://www.galaxyzoo.org/classify


So there may be something here that could make a tremendous contribution to
the project as well as be suitable as a thesis project.


Hope to hear back from someone. Email directly, Don't bother clogging up
> this mail list.
>
>

I hope these answers may be of more general interest, so I'm sending them
to ooo-dev as well.

Regards,

-Rob


> Cheers,
>
> Ian
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message