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:[email protected]] Sent: Saturday, May 11, 2013 11:02 To: [email protected] 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: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
