You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Rob Weir <ro...@apache.org> on 2013/05/11 20:02:20 UTC
How new developers get started
I'm thinking we have three kinds of volunteers:
1) Those who come here with a specific thing in mind that they want to
accomplish.
and
2) Those who are looking to help in any way they can
and
3) Those who are hoping to gain an experience or learn a skill
Maybe 3) is a subset of 2).
In some areas of the project, we'll get mainly type 2) or 3)
volunteers. For example, with QA. In most cases someone volunteers
without a specific thing in mind. They generally want to help out
where they can. There are exceptions, of course. For example we have
some volunteers who specifically want to test accessibility, but not
other areas. That is more like #1.
With developers we see all three types. For example, a developer from
another project might want to integrate their code from another
project into AOO. Or they are working on a port to BSD. Or they want
to add a specific feature. But we also have those who just want to
help in general.
The approach we've taken so far has been more of an
apprentice/journeyman/master progression, where we have new developers
start with learning to build, then progress to easy bugs, then simple
bugs, medium, etc. Eventually they know enough to do more significant
work. This helps make, over time, a very well-rounded contributor.
However, it is probably frustrating for type #1 volunteers who are
looking to do something specifically. It is also frustrating for
someone who wants #3, but doesn't have much time.
So I wonder what we can do to make it easier for any volunteer to
contribute? Some questions to think about:
1) Twice a year (once a semester) we get an influx of college students
who have been told by their professor to contribute to an open source
project. That is a type #3 developer. What can we line up for them
to work on in the Fall, that they can get started with quickly? If
someone has only 10 hours to offer, and we'll never here from them
again, what can they do?
2) Would it make sense to assemble "cookbooks" for some common
extension points, updating existing documentation where needed and
check in sample code to illustrate things like: adding a core
spreadsheet function, adding a chart type, adding an import/export
filter, etc. If there were maybe 8 core recipes for the most
promising areas for new developers, then they could get started
faster.
Of course it would also be a respectable position to say that we don't
want to encourage very many new features, and instead focus on
improving quality and performance, but be judicious in adding features
to avoid bloat. Encourage extensions, of course. But maybe we want
to start a serious effort at a native mobile app? That would
certainly attract new developers.
Regards,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: How new developers get started
Posted by "Dennis E. Hamilton" <or...@apache.org>.
Interesting question.
I think, if contribution has to do with the code base, it is very difficult to be able to operate without some way building the software to a level at least where checking for regressions and confirmation of the feature is possible. This means confirmation on more than one platform, of course. There does not seem to be much opportunity to operate in smaller, isolated modules and still provide complete work.
I am not competent enough with the code base to know how much the organization and interdependencies in the code are a barrier to having an abbreviated learning curve for focused tasks. My basic impression is that the amount of toolcraft that must be understood, especially if not already mastered, is quite daunting. I think this is challenging for category (1) where folks underestimate the amount of (3) that will be essential in order to be effective. It is always demanding to jump onto the middle of an already-moving train.
To have something more constructive, I think I have to take myself through the introduction and start-up materials and see what specific improvements to the on-ramp are achievable without disrupting the march to new releases. It is still in my job jar.
- Dennis
-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org]
Sent: Saturday, May 11, 2013 11:02
To: dev@openoffice.apache.org
Subject: How new developers get started
I'm thinking we have three kinds of volunteers:
1) Those who come here with a specific thing in mind that they want to
accomplish.
and
2) Those who are looking to help in any way they can
and
3) Those who are hoping to gain an experience or learn a skill
Maybe 3) is a subset of 2).
In some areas of the project, we'll get mainly type 2) or 3)
volunteers. For example, with QA. In most cases someone volunteers
without a specific thing in mind. They generally want to help out
where they can. There are exceptions, of course. For example we have
some volunteers who specifically want to test accessibility, but not
other areas. That is more like #1.
With developers we see all three types. For example, a developer from
another project might want to integrate their code from another
project into AOO. Or they are working on a port to BSD. Or they want
to add a specific feature. But we also have those who just want to
help in general.
The approach we've taken so far has been more of an
apprentice/journeyman/master progression, where we have new developers
start with learning to build, then progress to easy bugs, then simple
bugs, medium, etc. Eventually they know enough to do more significant
work. This helps make, over time, a very well-rounded contributor.
However, it is probably frustrating for type #1 volunteers who are
looking to do something specifically. It is also frustrating for
someone who wants #3, but doesn't have much time.
So I wonder what we can do to make it easier for any volunteer to
contribute? Some questions to think about:
1) Twice a year (once a semester) we get an influx of college students
who have been told by their professor to contribute to an open source
project. That is a type #3 developer. What can we line up for them
to work on in the Fall, that they can get started with quickly? If
someone has only 10 hours to offer, and we'll never here from them
again, what can they do?
2) Would it make sense to assemble "cookbooks" for some common
extension points, updating existing documentation where needed and
check in sample code to illustrate things like: adding a core
spreadsheet function, adding a chart type, adding an import/export
filter, etc. If there were maybe 8 core recipes for the most
promising areas for new developers, then they could get started
faster.
Of course it would also be a respectable position to say that we don't
want to encourage very many new features, and instead focus on
improving quality and performance, but be judicious in adding features
to avoid bloat. Encourage extensions, of course. But maybe we want
to start a serious effort at a native mobile app? That would
certainly attract new developers.
Regards,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: How new developers get started
Posted by Alexandro Colorado <jz...@oooes.org>.
On 5/11/13, Rob Weir <ro...@apache.org> wrote:
> I'm thinking we have three kinds of volunteers:
>
> 1) Those who come here with a specific thing in mind that they want to
> accomplish.
>
> and
>
> 2) Those who are looking to help in any way they can
>
> and
>
> 3) Those who are hoping to gain an experience or learn a skill
>
> Maybe 3) is a subset of 2).
>
> In some areas of the project, we'll get mainly type 2) or 3)
> volunteers. For example, with QA. In most cases someone volunteers
> without a specific thing in mind. They generally want to help out
> where they can. There are exceptions, of course. For example we have
> some volunteers who specifically want to test accessibility, but not
> other areas. That is more like #1.
>
> With developers we see all three types. For example, a developer from
> another project might want to integrate their code from another
> project into AOO. Or they are working on a port to BSD. Or they want
> to add a specific feature. But we also have those who just want to
> help in general.
>
> The approach we've taken so far has been more of an
> apprentice/journeyman/master progression, where we have new developers
> start with learning to build, then progress to easy bugs, then simple
> bugs, medium, etc. Eventually they know enough to do more significant
> work. This helps make, over time, a very well-rounded contributor.
> However, it is probably frustrating for type #1 volunteers who are
> looking to do something specifically. It is also frustrating for
> someone who wants #3, but doesn't have much time.
>
> So I wonder what we can do to make it easier for any volunteer to
> contribute? Some questions to think about:
>
> 1) Twice a year (once a semester) we get an influx of college students
> who have been told by their professor to contribute to an open source
> project. That is a type #3 developer. What can we line up for them
> to work on in the Fall, that they can get started with quickly? If
> someone has only 10 hours to offer, and we'll never here from them
> again, what can they do?
I think we could focus on the documentation of the easy hacks, some of
them are pretty outdated, some people have write to the list that the
code has change so much that the patch no longer work.
There is also a lot of information missing from a noob that want to
work in the code. He faces many folders and structures that might be
too overwhelming. So trying to understand how to navigate through the
code might be helpful.
There are some talks on different OOoCon that had talk about this
issue and also ways to improve the situation.
QA might be the easiest simple way to contribute, like confirming bugs
and or reporting language bugs, or similar things.
Donating templates, and writing up tutorials might be also a na easy
way to contribute specially if you are taking finance, math or
chemistry and want t explain how to use the more obscure calc
formulas.
Or simply develop an Add-In for a specific formula, like Taxes, or
something more regional.
>
> 2) Would it make sense to assemble "cookbooks" for some common
> extension points, updating existing documentation where needed and
> check in sample code to illustrate things like: adding a core
> spreadsheet function, adding a chart type, adding an import/export
> filter, etc. If there were maybe 8 core recipes for the most
> promising areas for new developers, then they could get started
> faster.
>
> Of course it would also be a respectable position to say that we don't
> want to encourage very many new features, and instead focus on
> improving quality and performance, but be judicious in adding features
> to avoid bloat. Encourage extensions, of course. But maybe we want
> to start a serious effort at a native mobile app? That would
> certainly attract new developers.
>
> Regards,
>
> -Rob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
Alexandro Colorado
Apache OpenOffice Contributor
http://es.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: How new developers get started
Posted by Alexandro Colorado <jz...@oooes.org>.
On 5/13/13, Guy Waterval <wa...@gmail.com> wrote:
> Hi Alexandro,
> Hi all,
>
> 2013/5/13 Alexandro Colorado <jz...@oooes.org>
>
>>
>> I co-lead the education project which included the use of classrooms
>> which as you say identify key developers and evolve into web training
>> around code. Eric manage to interface with schools in France and get
>> them on specific task and projects.
>>
>
> I suspected as a little, but I was not sure, because I work for educoo, but
> in another area, not in the code.
> Very happy to meet you Alexandro.
Sorry I think I misstyped, I wasn't involved with the classroom
activities directly but I understood the way it worked and where was
the documentation of the ones there were held
>
> A+
> --
> gw
>
--
Alexandro Colorado
Apache OpenOffice Contributor
http://es.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: How new developers get started
Posted by Guy Waterval <wa...@gmail.com>.
Hi Alexandro,
Hi all,
2013/5/13 Alexandro Colorado <jz...@oooes.org>
>
> I co-lead the education project which included the use of classrooms
> which as you say identify key developers and evolve into web training
> around code. Eric manage to interface with schools in France and get
> them on specific task and projects.
>
I suspected as a little, but I was not sure, because I work for educoo, but
in another area, not in the code.
Very happy to meet you Alexandro.
A+
--
gw
Re: How new developers get started
Posted by Alexandro Colorado <jz...@oooes.org>.
On 5/13/13, Guy Waterval <wa...@gmail.com> wrote:
> Hi Kay,
> Hi all,
>
> 2013/5/13 Kay Schenk <ka...@gmail.com>
>
>>
>> I think Guy's idea has merit, but...it would be difficult for us to
>> predict
>> where our next developer might be.
>>
>
> It's not my own idea. It's largely inspired from Eric Bachard's method with
> educoo.
> See here (Développement) : http://wiki.educoo.org/index.php/Partners/fr
> As I never met Eric, I don't know exactly the procedure that he uses.
> But I think it's a good approach. The big challenge consists to find the
> right internal contact, wellknown, appreciated by colleagues and students,
> and with the necessary power and capacity to port the idea internally.
I co-lead the education project which included the use of classrooms
which as you say identify key developers and evolve into web training
around code. Eric manage to interface with schools in France and get
them on specific task and projects.
http://wiki.openoffice.org/wiki/Education_ClassRoom/Practice
> But as you know, theory and practice are often different things. So, to
> test the validity of this method, I'm actually giving a try here :
> http://www.fr.ch/sfp/fr/pub/index.cfm because I think that I have found the
> right contact.
> But this method has not only advantages, but also inconvenients. Before
> running the ball, you have to be careful and verify before that you really
> have the required means to assist concretely to the development of the
> process. You will never have a second chance if you discredit due a lack of
> structure and organisation. That's the risk.
>
> A+
> --
> gw
>
>
>>
>>
>
--
Alexandro Colorado
Apache OpenOffice Contributor
http://es.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: How new developers get started
Posted by janI <ja...@apache.org>.
On Jul 3, 2013 10:20 PM, "Guy Waterval" <wa...@gmail.com> wrote:
>
> Hi Jan,
>
> 2013/7/3 janI <ja...@apache.org>
>
> >
> >
> > let me know if you need help from a (nearly) local developer.
> >
>
> Thank you for your answer.
> "Nearly local" ? I situated you in Denmark, I should review my geography.
> For me "nearly local" is 100 – 200 km ...
I am danish, but live in spain. Nearby might depend on your life, I have
worked in most parts of the world so < 500km is car distance, and a short
haul flight is nearby :-)
rgds
jan I
> As this info evening will probably reach 100% MS Office users/supporters,
I
> think there will not be many people ;-). For me 25 people should be a good
> result.
> But a surprise is always possible, ... as I'm already very surprised that
I
> can make this presentation .....
> I will know the number of participants in advance (probably one or 2
months
> before) and will announce it, bad of good result.
>
> A+
> --
> gw
>
> >
> >
Re: How new developers get started
Posted by Guy Waterval <wa...@gmail.com>.
Hi Jan,
2013/7/3 janI <ja...@apache.org>
>
>
> let me know if you need help from a (nearly) local developer.
>
Thank you for your answer.
"Nearly local" ? I situated you in Denmark, I should review my geography.
For me "nearly local" is 100 – 200 km ...
As this info evening will probably reach 100% MS Office users/supporters, I
think there will not be many people ;-). For me 25 people should be a good
result.
But a surprise is always possible, ... as I'm already very surprised that I
can make this presentation .....
I will know the number of participants in advance (probably one or 2 months
before) and will announce it, bad of good result.
A+
--
gw
>
>
Re: How new developers get started
Posted by janI <ja...@apache.org>.
On 3 July 2013 09:12, Guy Waterval <wa...@gmail.com> wrote:
> Hi all,
>
> 2013/5/13 Guy Waterval <wa...@gmail.com>
>
> > Hi Kay,
> > Hi all,
> >
> > 2013/5/13 Kay Schenk <ka...@gmail.com>
> >
> >>
> >> I think Guy's idea has merit, but...it would be difficult for us to
> >> predict
> >> where our next developer might be.
> >>
> >
> > It's not my own idea. It's largely inspired from Eric Bachard's method
> > with educoo.
> > See here (Développement) : http://wiki.educoo.org/index.php/Partners/fr
> > As I never met Eric, I don't know exactly the procedure that he uses.
> > But I think it's a good approach. The big challenge consists to find the
> > right internal contact, wellknown, appreciated by colleagues and
> students,
> > and with the necessary power and capacity to port the idea internally.
> > But as you know, theory and practice are often different things. So, to
> > test the validity of this method, I'm actually giving a try here :
> > http://www.fr.ch/sfp/fr/pub/index.cfm because I think that I have found
> > the right contact.
> > But this method has not only advantages, but also inconvenients. Before
> > running the ball, you have to be careful and verify before that you
> really
> > have the required means to assist concretely to the development of the
> > process. You will never have a second chance if you discredit due a lack
> of
> > structure and organisation. That's the risk.
> >
> I have received a positive answer. I have obtained an evening to present
> the AOO and Educoo projects during the first half of 2014.
>
> The event will be organized by:
>
> -
>
> L'association de la Formation Continue en Laboratoire :
> http://www.afcl.ch/
> -
>
> Le Centre de Perfectionnement Interprofessionnel : http://www.cpi.ch/
>
> The target audience will be the education and business areas. The CPI,
> which has the necessary contacts in the business and education areas, will
> take in charge the promotion.
> The date and location will be defined at the end of the year, once the
> number of participants will be known.
>
let me know if you need help from a (nearly) local developer.
rgds
jan I.
>
> A+
> --
> gw
>
> >
> >
> >
>
Re: How new developers get started
Posted by Guy Waterval <wa...@gmail.com>.
Hi all,
2013/5/13 Guy Waterval <wa...@gmail.com>
> Hi Kay,
> Hi all,
>
> 2013/5/13 Kay Schenk <ka...@gmail.com>
>
>>
>> I think Guy's idea has merit, but...it would be difficult for us to
>> predict
>> where our next developer might be.
>>
>
> It's not my own idea. It's largely inspired from Eric Bachard's method
> with educoo.
> See here (Développement) : http://wiki.educoo.org/index.php/Partners/fr
> As I never met Eric, I don't know exactly the procedure that he uses.
> But I think it's a good approach. The big challenge consists to find the
> right internal contact, wellknown, appreciated by colleagues and students,
> and with the necessary power and capacity to port the idea internally.
> But as you know, theory and practice are often different things. So, to
> test the validity of this method, I'm actually giving a try here :
> http://www.fr.ch/sfp/fr/pub/index.cfm because I think that I have found
> the right contact.
> But this method has not only advantages, but also inconvenients. Before
> running the ball, you have to be careful and verify before that you really
> have the required means to assist concretely to the development of the
> process. You will never have a second chance if you discredit due a lack of
> structure and organisation. That's the risk.
>
I have received a positive answer. I have obtained an evening to present
the AOO and Educoo projects during the first half of 2014.
The event will be organized by:
-
L'association de la Formation Continue en Laboratoire :
http://www.afcl.ch/
-
Le Centre de Perfectionnement Interprofessionnel : http://www.cpi.ch/
The target audience will be the education and business areas. The CPI,
which has the necessary contacts in the business and education areas, will
take in charge the promotion.
The date and location will be defined at the end of the year, once the
number of participants will be known.
A+
--
gw
>
>
>
Re: How new developers get started
Posted by Guy Waterval <wa...@gmail.com>.
Hi Kay,
Hi all,
2013/5/13 Kay Schenk <ka...@gmail.com>
>
> I think Guy's idea has merit, but...it would be difficult for us to predict
> where our next developer might be.
>
It's not my own idea. It's largely inspired from Eric Bachard's method with
educoo.
See here (Développement) : http://wiki.educoo.org/index.php/Partners/fr
As I never met Eric, I don't know exactly the procedure that he uses.
But I think it's a good approach. The big challenge consists to find the
right internal contact, wellknown, appreciated by colleagues and students,
and with the necessary power and capacity to port the idea internally.
But as you know, theory and practice are often different things. So, to
test the validity of this method, I'm actually giving a try here :
http://www.fr.ch/sfp/fr/pub/index.cfm because I think that I have found the
right contact.
But this method has not only advantages, but also inconvenients. Before
running the ball, you have to be careful and verify before that you really
have the required means to assist concretely to the development of the
process. You will never have a second chance if you discredit due a lack of
structure and organisation. That's the risk.
A+
--
gw
>
>
Re: How new developers get started
Posted by Kay Schenk <ka...@gmail.com>.
On Sat, May 11, 2013 at 12:18 PM, Guy Waterval <wa...@gmail.com>wrote:
> Hi Rob,
> Hi all,
>
> 2013/5/11 Rob Weir <ro...@apache.org>
>
> > I'm thinking we have three kinds of volunteers:
> >
> > [...]
> >
> > 1) Twice a year (once a semester) we get an influx of college students
> > who have been told by their professor to contribute to an open source
> > project. That is a type #3 developer. What can we line up for them
> > to work on in the Fall, that they can get started with quickly? If
> > someone has only 10 hours to offer, and we'll never here from them
> > again, what can they do?
> >
>
> Why not to try to establish a durable collaboration directly with some
> schools or universities. So, you can deal with a limited number of persons,
> the teachers, who can after organize some projects as exercices for their
> students. The students could directly worked under the mentoring of their
> teachers. The first year could be more difficult for the professors, to
> learn and adapt to the system but after the things could be more easy to
> manage and it could be also motivating for students to make real work for a
> real project.
> But OK, for me the code is a blackbox, I don't know if such an organisation
> is possible or a lost of time for everybody.
>
> A+
> --
> gw
>
> >
> >
>
I think Guy's idea has merit, but...it would be difficult for us to predict
where our next developer might be.
I have been thinking about our "development" process a lot over the last
few months. We've done some "reasonable" things, like attemptint to mark
issues that are easy, etc.
One thing that might be a big obstacle for new developers is the build
environment itself -- a mixture of variety of languages, etc., and what we
use for the build process -- command line. We've already had a bit of
discussion about this.
New developers are probably used to some kind of GUI environment -- Visual
Studio, Eclipse, NetBeans, etc. I think our current build process is not
suitable to these kinds of tools. We need to put more effort into
retooling to make this a reality. I know some work is already started on
this.
Additionally, it takes a LONG time to build. I would think the length of
time it takes to do a complete build is also not something new developers
would be used to. We have many dependencies to build some portions
(modules). I understand these can not be eliminated, but we could certainly
use much more information on how to go about "partial builds" and integrate
them more easily.
So, no answers from me, just some things I've been thinking about lately.
--
----------------------------------------------------------------------------------------
MzK
"God, grant me the serenity to accept the things I cannot change,
The courage to change the things I can,
And wisdom to know the difference."
-- "The Serenity Prayer", adapted from Reinhold Niebuhr
Re: How new developers get started
Posted by Guy Waterval <wa...@gmail.com>.
Hi Rob,
Hi all,
2013/5/11 Rob Weir <ro...@apache.org>
> I'm thinking we have three kinds of volunteers:
>
> [...]
>
> 1) Twice a year (once a semester) we get an influx of college students
> who have been told by their professor to contribute to an open source
> project. That is a type #3 developer. What can we line up for them
> to work on in the Fall, that they can get started with quickly? If
> someone has only 10 hours to offer, and we'll never here from them
> again, what can they do?
>
Why not to try to establish a durable collaboration directly with some
schools or universities. So, you can deal with a limited number of persons,
the teachers, who can after organize some projects as exercices for their
students. The students could directly worked under the mentoring of their
teachers. The first year could be more difficult for the professors, to
learn and adapt to the system but after the things could be more easy to
manage and it could be also motivating for students to make real work for a
real project.
But OK, for me the code is a blackbox, I don't know if such an organisation
is possible or a lost of time for everybody.
A+
--
gw
>
>