On 16/03/15 at 10:13 +0100, martin f krafft wrote: > also sprach Lucas Nussbaum <leader@debian.org> [2015-03-16 09:45 +0100]: > > Obviously I'm not in a position to make long term commitments as > > the DPL. I'd welcome "crazy ideas" in that area, at least in > > a brainstorming phase. Maybe you could start by working on a list > > of possible benefits, and then discuss with the DPL and the > > project which ones we are willing to give to sponsors? > > Okay, so then let's assume we identify perk Foo; now there are three > possible scenarios: > > a) "you know best, do as you see fit" — okay, forget that… ;) > b) "nice perk, but I think this should not be Silver but Gold and > up" > c) "no way we will offer this" from n people, "good idea" from > m people > > I can only dream of (a), and (b) would be really useful feedback. > But what do we do in the case of (c)? Scratch it for lack of > consensus? Push it anyway? What if it's hugely successful with our > sponsors and doesn't change the project really, once people have > come to accept it? What if it's a big failure and we won't do it > again? > > I am asking all these questions now because such sponsorship > brochure is a lot of work. I don't think any small team among us > will be able to just get it right, and being able to obtain feedback > from the community will be extremely useful. > > At the same time, however, I'd hate to create all this work (which > does involve speaking with sponsors at some point), only to find > that the efforts will get stalled because the Debian community can't > agree to place this in the hands of a few and ride along. > > The DebConf15 brochure had some perks at some time that caused > vicious debates, and while we removed the contentious ones, I think > that the only reason we managed to actually get this brochure out > was due to time pressure and just pushing things, which may have > alienated some people. > > In the context of Debian partners, we do not have this time pressure > and we don't have the ability to drive this to completion, unless > delegated. Obviously, nobody would be interested to go against the > majority, but knowing that there won't be consensus on everything, > one still needs to be able to make a move with the support of the > project. I think that it is the role of the DPL to break ties in that context, under "Make any decision for whom noone else has responsibility.". Of course, that should be done after hearing opinions, including from teams such as the press team and the www team that are likely to be affected by many of the perks. I don't think that it makes sense to delegate that authority to the partners team. Its role should be to: - *propose* a list of Perks - rank them in levels (Silver, Gold, ...) - decide on values for their levels - translate non-financial contributions to a common scale I agree that some perks might be contentious. But there are also a lot of "easy" ones. Maybe start by building a list, and we'll see where this goes? - Lucas
Attachment:
signature.asc
Description: Digital signature