On Mon, Jun 03, 2019 at 08:42:02PM -0400, Sam Hartman wrote: > >>>>> "Gunnar" == Gunnar Wolf <gwolf@debian.org> writes: > > Gunnar> I am aware your example is just an example - But don't you > Gunnar> think that following through with this would have a sad > Gunnar> effect on the www team: It would be equivalent to tell them, > Gunnar> "thanks for your work for so many years, but we have decided > Gunnar> it's a weak spot in the project, and we'd be much better off > Gunnar> if somebody else were to do it". > > If that were there reaction we shouldn't do it. > > I was imagining that if we went to www, treasurer, or a couple of other > teams and said things like > "Hey, from your last couple of reports you don't seem to be able to get > all the things done you want to dget done. We don't seem to get you > volunteers, but would you find it useful to have some money to contract > for some of those items? Because this is new, we'll help you out if you > don't have experience managing a contract well." > > I'd be really surprised if their reaction was to feel their work was not > valued if presented like that. > And if so, we apologize and move on. To me, a model that could work is a model of grants, like the Perl Foundations does. https://www.perlfoundation.org/grants-committee1.html https://www.perlfoundation.org/grant-ideas.html https://www.perlfoundation.org/how-to-write-a-proposal.html So people would be paid for fixed, delimited period, to achieve a specific goal. On the other hand, they would would have to report on their progress periodically, and would be held accountable with regards to what they proposed to work on, and they could be told what to work on or how to do the work. If they didn't reasonably achieve the goals they set themselves, that would be taken into consideration when evaluating future grant proposals from them. This makes that work a bit different from the volunteer work we all do in Debian, where our only obligation -- if it goes that far -- is to not block others from doing their own volunteer work. Coming back to the www team example, one way of mitigating, or maybe even elimitating, such negative reactions would be to encode in the evulation criteria for grant proposals that any proposal that is tightly linked to the work of an existing Debian team should be signed-off by that team, or require some member of the team to volunteer to act as "manager" for that grant before it is approved, or give that team veto power over the acceptance of the grant. i.e. such grant would only be accepted if the "affected" Debian team is happy with it.
Attachment:
signature.asc
Description: PGP signature