pcb-rnd knowledge pool
How to contribute
| contrib1 by Tibor 'Igor2' Palinkas on 2018-04-29 | Tags: howto, contribution, rules, goals, project, strategy, vision, accept, refuse |
Abstract: What sort of contribution works with pcb-rnd? How to best join your effort with the long term goals of the project?
Any contribution is welcome that is in line with the project directions. This is not limited to programming: we need a lot of user contribution, documentation writing, contribution in support.
"in line with project directions"
The project has a leader. The leader has a vision which is basically a clear path for where the project is at now and where it should be tomorrow. This vision is always very detailed for the next few months, reasonably detailed in an 1 year scale but there are some vague plans for even the next decade. Your contribution is best spent if what you want to work on fits in this vision.
The following diagram shows the concept:
What happens (1)
The path the project will eventually take is the thick green line marked as "1". Of course it is impossible to tell how exactly this line will curve, so the drawing does not show what we know today but how we see it looking back from some arbitrary time from the future.
What is likely to happen (2)
Looking at this from today, it looks like the green polygon marked with "2"; this represents that path the project is likely to take in the near future. It's not a line, it's a polygon, because there's always a small amount of uncertainty. But it is rather narrow: we are not developing randomly, we have a plan.
If you want to contribute but do not know what exactly to do, best ask the project leader - he will offer you a few potential tasks that are all within this green polygon.
What could happen, if you stand up (3)
If you have a specific feature you want to implement, discuss it with the leader - it may be within "2". If not, it may be within "3", a wider blue polygon that represents things that are not what we originally planned to do, but new contributors investing some time in. Within this area it is safe to work: your contribution is most likely included and you will get support implementing it. However, as your effort was not in the original plan, it's most likely considered a less important goal than anything that was in the original plan - thus your feature will have slightly lower priority. However, in a sense this is the simplest way to affect project direction: as a result of a successful implementation of anything within "3", the final green line is bent a bit toward that point.
What may happen, if you are real dedicated (4)
There are always features that are even further out from the plans, but are still acceptable (don't contradict with the project goals, don't go straight against the values of the project). These features are represented by the wide cyan polygon, marked as "4". If you want to work on such a feature, (and want it to get accepted) you should:
- first work on something in "2" or "3" to prove your skills
- discuss the feature with the leader before you start implementing it
- be accessible (mailing list, IRC)
- make sure you have enough time - regular, allocated time, like a dedicated 4..8 hours a week
These considerations (or stricter rules) are set up because features in these group are those that we do not want to spend time on. If you want to, you can, but we must make sure that we don't end up with a half-finished subproject and that supporting this subproject doesn't cost more than your contribution brings. (We have had examples of both of these in the past.)
Things that won't happen (5)
Sometimes a contributor wants to implement something that is simply not in-line with the project. We do not accept such features - please implement it for yourself, locally, or distribute it as a standalone addon.