For very small abandoned projects, nobody is around to do anything, even to review a
patch.
For a slightly bigger project, someone is around to review a patch and explain you how to
write one, and where to get started. The process of you writing it is slow, and the
process of them reviewing it may also be slow.
For a next bigger project, 2-3 volunteer maintainers are around. They hear every word from
feedback and prioritise them based on how easy they are to work around, and how well they
fit a project scope. (Usually a lot of things fit project scope as long as it's
designed and coded well.)
As a project goes bigger, more time is dedicated to unit tests. A volunteer would read
feedback and review patches, but more effort would be spent into making the project not
fall apart. Code review, unit tests, issue tracker, and again everything people request
eventually gets in somewhere. Again someone is around who can explain you where to get
started if you'd like to pick up your own request or someone else's.
As a project goes even bigger, it usually remains modular. It is relatively easy for you
to get started by reading a very small module and coding your thing in. Again someone is
around who sees you as a new potential volunteer, and is happy to explain you how things
work.
...
When a project has an employee (or a GSOC student) coming in, something needs to
prioritise their work. What issues to hand over to them to get them complete in no time?
...
Answer to this question may vary. It is hard to answer it right - there is more than one
way to do it.
Some things come to my head about what should not be done:
1/ Miss community feedback. [For bigger projects, you /will/ have to consciously skip
(note: this does not mean miss, it is a different word) some, to not make the thing a
features mess. Simplicity is the key of success.]
2/ Come up with big non-modular projects.
3/ Lose consistency by working on big enhancements out of the blue, leaving the rest of
functionality or interface behind.
4/ Write code which fails to be reusable.
5/ Fail to write documentation.
6/ Fail to showcase, reveal, and expose the features the employee added, which are
reusable.
7/ Fail to support community work.
8/ Fail to meet original project mission.
Could someone please point me specifically to where (4) and (6) are not failing within
Wikimedia Engineering?
In other words:
- What reusable things come out of each Wikimedia Engineering project?
- Where can I find out about them easily without asking you to find them for me by hand?
svetlana