incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Alexandre Ferreira Leite <leonardof...@gmail.com>
Subject Re: Ideas for Growing the ODF Toolkit Community
Date Tue, 07 Jan 2014 18:25:10 GMT
Thanks for the reply Rob!


On 7 January 2014 14:11, Rob Weir <robweir@apache.org> wrote:

> On Thu, Jan 2, 2014 at 1:08 PM, Leonardo Alexandre Ferreira Leite
> <leonardofl87@gmail.com> wrote:
> >> Ideas for Growing the ODF Toolkit Community
> >
> > Hi guys,
> >
> > I'm new here in the list.
> > I have submitted a bug report [1], and a question about it (I'm trying to
> > fix it).
> > But no reply was given to me.
>
>
> I think what you discovered is accurate.  What I do in my code is
> start with a document template, an ODF file that has my default styles
> already defined.  Then my code loads that document, modifies it and
> writes out the final document.  I think it is is a lot easier to
> manage styles in OpenOffice than in Java code.
>
>
> > I know it was not an easy question, but maybe replying newcomers
> > is a good way to help "growing the whole thing".
> > And I'm sorry if I did not pay attention to some required rule...
> >
>
> This is a good point.
>
> > Just a note: a new release would be great...
> > I could not use the current versions downloading the JARs,
> > because there are some crazy dependencies that brings trouble (I did not
> > remember exactly the problem now).
> > The only way was downloading the repo, mvn install,
> > and declaring dependency on my project's pom.
> > By the way, a "maven release" would be great too
> > (using an online maven repository).
> >
>
> Someone (Svante?) published the libraries to Maven Central here:
>
> http://search.maven.org/#search|ga|1|g%3A%22org.apache.odftoolkit%22
>
> But that looks like an older version.
>
> -Rob
>
> > thanks,
> > Leonardo Leite
> >
> > [1] https://issues.apache.org/jira/browse/ODFTOOLKIT-349
> >
> >
> >
> >
> >
> > On 1 January 2014 16:09, Rob Weir <robweir@apache.org> wrote:
> >
> >> I'd like to see if we can grow the community a bit more in the next
> >> month or so.  We've been a very quiet project compared to some.  We
> >> have just two public mailing lists, no blog, no new articles written
> >> about us.  If we can better publicize the project then we will grow.
> >>
> >> I think of a pyramid.  At the base are the users, those who get some
> >> benefit from using the ODF Toolkit.  Some fraction of the users will
> >> contact the project, maybe submit a bug report.  They also help spread
> >> the word about the project to their colleges.  Some fraction of these
> >> "engaged" users will then send a patch or express interesting in
> >> helping with the project.  That's the next level up on the pyramid.
> >> And some fraction of those developers will become committers.
> >>
> >> The idea of this analogy is if we grow the base, we grow the whole
> >> thing, including contributors and committers.
> >>
> >> So a suggestion on how we can make a big advance:
> >>
> >> 1) Let's get out a new release in January.
> >>
> >> 2) In parallel we can revise our "get involved" page:
> >>
> >> http://incubator.apache.org/odftoolkit/get-involved.html
> >>
> >> For example, do we have any specific ideas for what new developers
> >> can/should work on?  Obviously bug reports. But do we have a "wish
> >> list" of possible enhancements/features that we should list?  It makes
> >> it easier for a new volunteer if we can point to some ideas.
> >>
> >> If others can contribute ideas I can edit them on the website.
> >>
> >> 3)  To attract more users we need an up to date tutorial or demo.
> >> Maybe what we have is fine?  Or do we need something "sexier"?
> >>
> >> 4) With the new release I can help publicize the Toolkit and the
> >> project on my personal blog.  And we can all help in this area with
> >> Twitter, etc.  If we want we can request a project blog via
> >> blogs.apache.org.  This have many readers as well.
> >>
> >> Any other ideas?
> >>
> >> -Rob
> >>
>

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