From: "Rémi Denis-Courmont" <remi@remlab.net> To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [RFC] STF 2025 Date: Mon, 20 May 2024 21:51:25 +0300 Message-ID: <3884182.pYkPcsdkp7@basile.remlab.net> (raw) In-Reply-To: <ddda78d9-b498-4427-8fe5-13c6034805a4@mail.de> Le sunnuntaina 19. toukokuuta 2024, 14.29.43 EEST Thilo Borgmann via ffmpeg- devel a écrit : > [...] > > >> * Fund administrative / maintainance work (one example is the mailman > >> upgrade that is needed>> > >> with the next OS upgrade on one of our servers (this is not as trivial > >> as one might expect). Another example here may be some git related > >> tools if we find something that theres a broad consensus about. > > > > I agree that this should be paid but I would expect that STF would not be > > too keen on it, not that I'd know really. > We should absolutely pay for such activity and STF is very well willing > to fund such things. Again, I don't know but that seems to stray from their stated goals. Also this is most certainly not a full-time job, and it requires a very high level of trust. In practice, what this really means is paying Michael. It is more of a question whether STF is willing to pay for this, and whether a reasonable task description with a reasonable average prorated workload and a pay can be defined. > > And again, it is completely reasonable to be paid for that, and also for > > code reviews and writing test cases (if we want to complete the menial > > task list), but I am perplexed as to STF's stance on that. > Same as above about that we should and STF would. > Especially since no corporate interest usually pays anyone for these tasks Sadly true, but... > (in case of reviews it might of course be considered a good thing). I think some review is better than none. There may be conflict of interests, but they are weighed by the risk of being caught abusing the review process. > The one problem to solve here AFAICT is we don't know exactly what > quantity of bugs, reviewable code submissions and other maintenance work > will come up in the next 12 months. People would normally do this as interruption task whilst developing code (or writing documentation or whatever else) when there are no bugs and no review pending. Just like server admin, this is not a full-time job and we can't really pretend that it is. > So it renders impossible to define in prior the workload, milestones and > compensation per contributor interested as we did this year for > well-defined tasks. If you can't define workload, deliverables and cost, you wouldn't normally get funding. So I don't see much point in arguing about this. We can all agree that it is a conundrum, and that won't make the requirement go away. > What we should consider IMO is defining the tasks (patch review, bug > review & fix, FATE extensions, checkasm extensions, etc. as well such > things for the administrative tasks from above) and defining a budget > for these tasks. In principles, all work deserves compensation. In practice, giving money in such small units sounds extremely impractical. Also... > Then, allow 'everyone interested' (aka git push access?) to claim a part > of that budget every N-months, depending what the corresponding > contributor actually did and can somehow be determined. ... with the current relatively small budget (even including STF funding), that would be a pittance for most people. I think we are better off paying a few people correctly than paying a lot of people peanuts - even leaving aside the administrative gas factory that this would add up to. > > This is not something that STF should pay for, AFAIU. This is something > > that professionals should pay out of their budget (or their employer's) > > for the business events, and SPI for cheap/community events, IMO. > I think we should fund all non-b2b appearances. Of course we should reimburse reasonable transporation and accomodation costs, and of course goodies, as as been done already. Whether it's B2B, B2C or community is not really the criterion: we should simply *not* pay for booth space, booth installation or exhibitor tickets. It just so happens that in practice mostly only community conferences would allow us to hold a booth for free. > About b2b, I wouldn't like our donation based money to be spent. We had > corporate sponsorship in the past not having to think about it and > possibly will have that as well in the future. The companies are > interested in seeing us there and some are willing to pay for that > happening. If the conference/tradeshow organisers want to use FFmpeg as a marketing argument to attract attendees, they should provide a free booth. There is simply no way that FFmpeg would recoup its expenditure on a booth. It is not selling anything, additional donations are very unlikely to end us in the black, and the chance of finding a new contributor at B2B or B2C shows is also pretty much zilch. If the booth is paid for by a business, then well that's a case of "professionals paying for it out of their budget", assuming that there are no hidden costs such as setup costs. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2024-05-20 18:51 UTC|newest] Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-05-17 13:49 Michael Niedermayer 2024-05-17 14:43 ` Ronald S. Bultje 2024-05-19 11:29 ` Thilo Borgmann via ffmpeg-devel 2024-05-17 14:47 ` Rémi Denis-Courmont 2024-05-19 11:29 ` Thilo Borgmann via ffmpeg-devel 2024-05-19 12:08 ` Andrew Sayers 2024-05-20 18:51 ` Rémi Denis-Courmont [this message] 2024-05-21 18:43 ` Thilo Borgmann via ffmpeg-devel 2024-05-21 19:42 ` Rémi Denis-Courmont 2024-05-21 19:43 ` Rémi Denis-Courmont 2024-05-21 21:34 ` Thilo Borgmann via ffmpeg-devel 2024-05-21 21:34 ` Thilo Borgmann via ffmpeg-devel 2024-05-22 12:27 ` Rémi Denis-Courmont 2024-05-24 7:11 ` Thilo Borgmann via ffmpeg-devel 2024-05-24 7:56 ` Rémi Denis-Courmont 2024-05-24 21:42 ` Michael Niedermayer 2024-05-17 15:08 ` Vittorio Giovara 2024-05-17 19:08 ` Michael Niedermayer 2024-05-17 15:25 ` Andrew Sayers 2024-05-17 15:26 ` Derek Buitenhuis 2024-05-17 18:50 ` Michael Niedermayer 2024-05-17 19:22 ` Derek Buitenhuis 2024-05-17 19:54 ` Rémi Denis-Courmont 2024-05-24 9:56 ` Andrew Sayers 2024-05-24 10:50 ` Thilo Borgmann via ffmpeg-devel 2024-06-01 15:19 ` Tomas Härdin 2024-06-02 18:01 ` Michael Niedermayer 2024-06-02 18:16 ` Rémi Denis-Courmont 2024-06-02 20:14 ` Tomas Härdin 2024-06-03 6:50 ` Thilo Borgmann via ffmpeg-devel 2024-06-03 7:55 ` Rémi Denis-Courmont 2024-06-03 11:35 ` Rémi Denis-Courmont [not found] ` <85865A16-B2BD-419C-857B-445ED6354604@cosmin.at> 2024-06-03 16:43 ` Cosmin Stejerean via ffmpeg-devel 2024-06-03 17:36 ` Rémi Denis-Courmont [not found] ` <EF00C7AD-23E4-4AFB-BEC0-F9139F7B6051@cosmin.at> 2024-06-03 17:48 ` Cosmin Stejerean via ffmpeg-devel 2024-06-03 18:18 ` Rémi Denis-Courmont [not found] ` <8BE7B5F7-E7FD-4F73-9239-91B8D289452A@cosmin.at> 2024-06-03 18:58 ` Cosmin Stejerean via ffmpeg-devel 2024-06-03 19:26 ` Rémi Denis-Courmont [not found] ` <C07B2718-2EDD-42CF-8F2E-BED82E14049A@cosmin.at> 2024-06-03 20:57 ` Cosmin Stejerean via ffmpeg-devel 2024-06-03 22:58 ` Vittorio Giovara [not found] ` <C3243629-53D2-4595-A82D-35D298B965EF@cosmin.at> 2024-06-04 1:01 ` Cosmin Stejerean via ffmpeg-devel 2024-06-04 6:53 ` Vittorio Giovara 2024-06-04 6:54 ` Paul B Mahol 2024-06-04 7:08 ` Vittorio Giovara 2024-06-04 10:09 ` Paul B Mahol 2024-06-04 10:50 ` Vittorio Giovara 2024-06-04 12:01 ` Paul B Mahol 2024-06-04 12:52 ` Vittorio Giovara 2024-06-04 17:38 ` Paul B Mahol 2024-06-04 18:17 ` Vittorio Giovara 2024-06-05 7:20 ` Marton Balint 2024-06-05 8:12 ` Vittorio Giovara 2024-06-05 9:18 ` Rémi Denis-Courmont 2024-06-05 9:31 ` Rémi Denis-Courmont 2024-06-05 13:42 ` Paul B Mahol 2024-06-06 0:07 ` Michael Niedermayer 2024-06-06 10:04 ` Vittorio Giovara [not found] ` <546DF7EF-0061-4126-AE81-3CD0EC24ED9A@cosmin.at> 2024-06-04 15:47 ` Cosmin Stejerean via ffmpeg-devel 2024-06-04 18:24 ` Vittorio Giovara 2024-06-04 21:21 ` Michael Niedermayer 2024-06-04 22:23 ` Vittorio Giovara 2024-06-03 15:00 ` Vittorio Giovara 2024-06-03 15:41 ` Tomas Härdin 2024-06-18 14:41 ` Tomas Härdin 2024-06-04 15:04 ` Andrew Sayers
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=3884182.pYkPcsdkp7@basile.remlab.net \ --to=remi@remlab.net \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git