Re: Paths into Debian
Just a few of my own comments, mainly from interacting with GSoC
students, although this could be just as applicable to anybody:
- While people joining the NM process or the mentors list are aiming to
have some package added, students don't always come with a clear idea of
some package they want to create or maintain. Rather, they have an idea
about the topic they want to work with (e.g. security, VoIP).
- I've started creating wishlist bugs in my packages, these provide
useful coding tasks for people, especially students. They are
particularly useful for GSoC applicants, because they need to
demonstrate their coding skills during the selection process. Even
maintainers who have no time to interact with GSoC or anything could
still create such bugs and tag them in some way to provide entry points
for people to start contributing.
- Maintainer lists (e.g. pkg-voip-maintainers) are full of automated
notifications and may scare people away. More effort may be needed to
separate discussion from other automated stuff.
- the github fork and "pull request" phenomenon. It is tremendously
easy for people to contribute what they want. There has been some talk
about getting something like Gerrit into Alioth, that may help us in
that direction.
- Having a single VCS (e.g. Git or Mercurial and abolishing SVN, CVS)
would also help reduce complexity of Alioth tool support and lower the
learning curve for first-time contributors.
On 29/08/13 20:39, Filipus Klutiero wrote:
> It also briefly mentions the "fundraising path" and the "press path",
> which are rarely directly accessible for newcomers. Your talk shows
> improvements which could be done to our roads and to our maps:
> http://www.debian.org/intro/help
> http://www.debian.org/devel/join/
> http://www.debian.org/devel/join/newmaint
The "press path" has some risk associated with it
Look at the "Jayme Diaz" video to see an extreme example of the press
cutting someone to pieces.
The only way to deal with that is to either have people who know their
topic inside out (e.g. because of long time Debian/free software
involvement) or engaging experienced media handlers.
Reply to: