> So while I agree with everything Bertrand said I don’t think it resolves the real issue. TideLift is providing a guarantee to its customers that projects it sponsors meet certain standards. The standards they are looking for should really be set by the ASF, not individual projects.
This is the part I do not understand. What Tidelift can promise to their customers and on what basis? According to ASF rules where only individuals in the project can make decisions - this means that Tidelift has no mechanisms whatsoever to fulfill their promise. And if ASF sets the standards - why do we need Tidelift at all ? To be perfectly blunt - I am afraid that until Tidelift resolves any of the real problems of individual committers we mentioned with Bertrand (including facilitating direct relationship commiter <> stakeholder), I do not see what's the added value of Tidelift. Seems like unnecessary intermediary. J. On Mon, Feb 28, 2022 at 5:10 PM Ralph Goers <ralph.go...@dslextreme.com> wrote: > First, I would like to clarify Gary’s email as I don’t think he > characterized it quite correctly. > The Logging PMC concluded we could not be part of an arrangement with > TideLift and > that the issues needed to be worked out at the foundation level. The > primary issue was > that TideLift had requirements on advertising and process details that > required approval > of the PMC in order for individuals to be able to be paid. We met with a > Google > security team in January and had similar issues where they required a > process that isn’t > aligned with the ASF’s requirements on how releases are to be performed. > > Second, from my point of view the ASF should have discussions with > TideLift and Google to > see if those issues can be resolved. The ideal scenario would be that > TideLift and Google > can simply sponsor individuals from any ASF project because all ASF > projects must > conform to guidelines that meet their criteria - i.e. the PMC doesn’t even > have to be > involved. But this obviously requires that the foundation work with these > third parties to > either improve our processes where needed or get the third party to accept > our processes. > > So while I agree with everything Bertrand said I don’t think it resolves > the real issue. > TideLift is providing a guarantee to its customers that projects it > sponsors meet certain > standards. The standards they are looking for should really be set by the > ASF, not > individual projects. > > Ralph > > > > On Feb 28, 2022, at 5:03 AM, Bertrand Delacretaz <bdelacre...@apache.org> > wrote: > > > > Hi, > > > > Le lun. 28 févr. 2022 à 11:06, Jarek Potiuk <ja...@potiuk.com> a écrit : > >> ...the relationships I have is direct relationship with the > >> stakeholders. Let's deel, GitHub Sponsors, SAP Ariba are merely > "removing > >> bureaucratic obstacles" but they are not "between" me and my > stakeholders. > >> They are "on a side". They get a small cut sometimes (which I gladly > pay) > >> but I want to talk to the stakeholders directly without any > intermediaries > >> and establish a long-term relationship with them as an individual.... > > > > I think that's a key point, and listing such requirements for > > platforms that can help our contributors get funding sounds useful. > > > > Here's a quick list of initial requirements that we might include: > > -Contributors can get steady funding for their work > > -ASF is out of the loop of financial transactions > > -Contributors must use a standard ASF disclaimer (draft at [1]) > > -Contributors can establish a direct relationship with sponsors > > -Several "funding intermediaries" are available > > -ASF might define the wording that contributors can use when > > advertising themselves (based on facts, etc.) > > > > I like the idea of the ASF facilitating these things. > > > > Maintaining a comdev page that lists criteria like the above, with > > pointers to the relevant ASF policies, and lists intermediaries that > > our contributors have successfully used, might be a good start. > > > > -Bertrand > > > > [1] https://community.apache.org/committers/funding-disclaimer.html > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > For additional commands, e-mail: dev-h...@community.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
