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]
