To everyone who is working on this problem, thank you :-) On Tue, Jul 09, 2019 at 10:38:14AM +0200, Michael Kesper wrote: > Hi again, > > On 09.07.19 09:17, Michael Kesper wrote: > > I think this is still starting a little bit negative, maybe like this? > > > > If nobody adopts this package it will vanish from Debian. > > Do you care for this package being part of Debian? > ^^^^^^^ > Maybe change this "package" to software, as I just realized that term > is used a little bit too often here and users don't care about > "packages" but about using software. > The Case of the Disappearing Orphans: Motivations for maintaining to open source software. To be fair, doesn't the QA team (and random acts of kindness) often keep these packages alive? Maybe say something about that, and also how placement into a team provides better support for both the package/software and prospective contributor? Also, in the interest of keeping things positive, is it worth noting that Debian has "an almost magical ability to transform users into developers" (I read that in an article somewhere, years ago)? Thus, maybe package orphaning bug reports can become a more smooth path for situating new contributors into whatever context has the best chance of maximising their long-term motivation and future contributions? > > If so, have a look at https://mentors.debian.net/intro-maintainers to > > understand best practices of maintaining a package. > > If you are new to Debian packaging, please read the tutorial > > https://www.debian.org/doc/manuals/debmake-doc/index.en.html and also > > study how other Debian maintainers package similar packages. > ^^^^^^^ ^^^^^^^^ > Don't know exactly how to phrase that better. Hm, I'm not sure. Ideally it seems like it would be nice if we could provide a bit more streamlined procedure for "similar packages". Eg: 1. What language is the package implemented in? 2. Is there a team for that? ...URL for intake page for new members to a team, with hello-world packaging example (technical reference) and a link to the git repo of a complex package that is a well-documented high quality model of the team standards. The language-specific Hello-world example should use dh, unless the team generally doesn't (eg: IIRC the Haskell team, et al). The complex package would be a learn-by-example for things like overrides. Contributors will eventually learn how to search & find the resources they need, but I've seen a number of emails expressing how new contributors feel laughed at for not being able to find the relevant information and solutions. Thanks again to everyone who is working on this! Regards, Nicholas P.S. has anyone yet volunteered to help out with that sphinx document conversion project.
Attachment:
signature.asc
Description: PGP signature