Hi,
janI schrieb:
On 9 May 2013 14:40, Rob Weir <robw...@apache.org> wrote:
On Thu, May 9, 2013 at 5:05 AM, janI <j...@apache.org> wrote:
[..]
It might make sense to make a list: What are all the things that a
new dev volunteer needs to know or do before they can make their first
patch?
+1
A new developer can help already before he is able to make a patch. My
first contribution was a comment to the function getRandbetween long
before I know any C++.
1) What knowledge do we assume as a pre-req? Obviously we cannot
tutor them in C++. But what else is an absolute prerequisite?
With the current build system, they need to have fundamental knowledge of:
- makefiles (we can provide a link, maybe it could be put in the
"introduction" course
- scripting languages (again with can provide links to documents)
Here I disagree. Such knowledge is not necessary. For example my last
issue 122263. That is all inside one file. You need not know anything
about makefiles or scripting languages. Make the barrier as low as possible.
2) Of the other items the need to know, what is already written down?
I bet a lot of it already exits, but it is scattered about and/or
out-of-date.
That is a bet I will not take, here is my list (what I missed, regina
described most of it in an earlier mail):
- a strict platfom related step-by-step build guide, with the variations
(debug for a single module, language version, normal build)
- An overview of our directory structure, with a short explanation what
is this directory containing
- An overview seen from the product e.g. writer consist of.
- helper tools
- Debug guide, how to do partial debugging (platform dependent), advice
on inspecting our objects (especially strings)
- Build guides pr. platform, with advice on rebuilding, especially if
with different configure (e.g. with/without language)
- short introduction to how we use svn (git?) and how to submit patches
(svn diff)
- A list of, at least but not limited to, pmc members and their field of
expertice, so a new person feels he/she knows us.
(actually such a list, helps a lot with the other missings)
I have one wild idea, which I do not know if it is can be done....extend
the introduction module with one lesson "solve your first bug", where we
make a step-by-step guide for solving a "real" bug, the idea is that the
developer can use it as a "template" to solve real bugs. This guide should
problaly come in 2 versions windows/linux.
And when the bug is fixed? Such lesson would need to be independent of a
bug.
Nevertheless a "solve your first bug"-page is a good idea. But each such
bug needs an experienced developer to guide a newcomer. Unfortunately
I'm not 'experienced' but need such mentor myself.
Such page would be better visible to new developers than searching in
Bugzilla for "easy" tags and finding nearly nothing.
3) Create a new index page (or update an existing one) to bring
together links to all this information.
+1
4) Where needed update this information
+1
All together these seems to be tasks to start as soon as possible
(immediately after release of 4.0?) and before any actions to appeal for
developers.
Kind regards
Regina
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
