20,741
edits
Implementing new features for FlightGear: Difference between revisions
Jump to navigation
Jump to search
m
Implementing new features for FlightGear (view source)
Revision as of 18:07, 17 May 2014
, 17 May 2014→Getting People involved
m (→Be persistent) |
|||
| Line 71: | Line 71: | ||
== Getting People involved == | == Getting People involved == | ||
One of the most common show-stoppers preventing people from succeeding with their ideas, feature requests or projects is the lack of networking, and the | One of the most common show-stoppers preventing people from succeeding with their ideas, feature requests or projects is the lack of networking, and the unwillingness to compromise and make sacrifices. | ||
The common pattern we get to see is that people want '''their''' particular idea to be implemented immediately, expecting others to drop pretty much anything else and provide first-class support to them. | |||
Obviously, this is not how things work - just imagine for a second, somebody were to ask you to drop your own ideas and projects in favor of some random new idea, in a volunteer project. | |||
However, there '''is''' a way to have your cake and still it eat, by going more slowly, and by sharing. | |||
In general, it is unlikely that you'll be able to directly form a team of people who share your motivation, goals and expertise - and even then, you may find yourself missing other components that are required for a successful project, such as expertise in certain areas (3D modeling, texturing, programming, scripting, effects or shaders etc). This is why you'll typically have to reach out other contributors and ask them to get involved. And this is also exactly where most people fail right from the beginning: because they're more focused on their own goals and projects, than demonstrating to fellow contributors, how they can help improve others lives. | To get people involved, you need to get them interested, and you need to motivate them. | ||
People are not just motivated by '''ideas''' but by actions that materialize, and short of that, by saving their own time. | |||
Usually, most contributors have different ideas about FlightGear, and very different priorities, skills and expertise. | |||
So the point really is compromising. Finding overlapping areas of interest, i.e. common goals. Very often, that means that people may not directly work towards the original goal/project (such as for example an improved multiplayer system, a weather system or even combat support), but rather some interim milestones, as part of some longer-term '''roadmap'''. | |||
That way, contributing becomes pretty much a '''journey''', where you may meet people willing to accompany you for a certain time, task and project, until their own goals have been reached. Sometimes this journey make take a few months or even years, but often it's really just a few weeks or even just days that someone finds some of your project overlapping with his own goals. | |||
In retrospective, this is exactly how some of the most popular base package projects took shape, despite a lack of momentum initially: People were willing to compromise their original goals by talking to others who had overlapping, or at least sufficiently similar, goals and found a way to collaborate to a certain degree, even though every contributor would still keep his own long-term goals and priorities in mind. | |||
In general, it is unlikely that you'll be able to directly form a team of people who fully share your motivation, goals and expertise - and even then, you may find yourself missing other components that are required for a successful project, such as expertise in certain areas (3D modeling, texturing, programming, scripting, effects or shaders etc). | |||
This is why you'll typically have to reach out other contributors and ask them to get involved. And this is also exactly where most people fail right from the beginning: because they're more focused on their own goals and projects, than demonstrating to fellow contributors, how they can help improve others lives, i.e. by learning more about other projects and efforts, and potentially overlapping areas. | |||
Conceptually, this boils down to thinking in terms of components, i.e. building blocks that need to be established in order to accomplish something. It is very likely that a dozen unrelated projects may benefit from very similar building blocks - typically, there's at least a handful of needs that projects may have in common. | Conceptually, this boils down to thinking in terms of components, i.e. building blocks that need to be established in order to accomplish something. It is very likely that a dozen unrelated projects may benefit from very similar building blocks - typically, there's at least a handful of needs that projects may have in common. | ||
Note that this doesn't have to do anything with programming, '''building blocks''' can just as well by non-coding items, like textures, sounds, instruments, 3D models etc. | |||
Successful contributors realize that such overlapping areas are an excellent opportunity to get others involved. | Successful contributors realize that such overlapping areas are an excellent opportunity to get others involved. | ||
Still, there may be areas with little, if any, momentum and where networking doesn't seem feasible, this is where you may have to | Still, there may be areas with little, if any, momentum and where networking doesn't seem feasible, this is where you may have to make an upront investment to get other contributors involved. | ||
== Be persistent == | == Be persistent == | ||