Why gitlab and not GitHub? If the intent is on making contribution from new developers easier, I think the workflow should be where the majority of developers are actively participating.
On Wed, Jan 29, 2025 at 11:32 AM Kieran Kunhya via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: > On Wed, Jan 29, 2025 at 7:01 PM Michael Niedermayer > <mich...@niedermayer.cc> wrote: > > > > Hi Yigithan > > > > Its good that you bring these issues up. > > Discussing about them is a step towards solving them > > > > see my coments inline below > > > > On Wed, Jan 29, 2025 at 06:51:40PM +0300, Yigithan Yigit wrote: > > > Hi Michael, > > > > > > I want to give some feedback before GSoC’25 as GSoC’24 participant. I > speak for myself but I know some of other colleagues are sharing similar > thoughts with me. > > > > > > First of all community has incredible talented people and I am not > even single percent of those people. However I tried my best during the > qualification stage and after that. My main problem was finding answer's > inside a huge codebase. I might come stupid ideas, bad implementations but > to be honest when I asked about something in IRC I couldn’t get any > answers, even in my volumedetect(qual patch) I couldn’t get a proper review > from community. > > > > > > > > Guessing contributors are mostly the passionate driven. I find that > passion beginning but lost day by day. I tried to share similar thought > during VDD, they told me this is normal and happening. Which shouldn’t be > in my opinion. If project wants to > > > > yes, i also agree that this should not happen > > > > > > > newcomers or continuous contributors people should be more welcoming. > I understand you can’t force people to review some patches but still there > are some parts needed to be change, I can’t say specifically which parts > but they should be changed. > > > > Its a complex problem > > > > The average age of developers is becoming older, (meaning there are > fewer new developers joining than in the past) > > > > many now are payed by companies to do specific work for a company. > > Meaning they have less time to do what the community and FFmpeg needs > > as they spend time to do what the company needs > > I think people should attempt to shift payed feature implementation > towards payed maintaince and > > reviewing patches, picking up an area and maintaining it as their day job > > > > What is impotant is to have maintainers for every part of the codebase. > > But to have a passionate and dedicated maintainer, often either he needs > > to have authority or needs to be paid. > > > > Both we fail at. AND also it needs the mindset that maintainers are > needed. > > > > For the payment, > > for example carl, who took care of the bug tracker for years (something > truly important) > > should have been hired by some company to continue that work, it would > have > > made economic sense to these companies actually. > > > > Another example for Payment is the souvereign tech fund. last year we > for the > > first time got accepted BUT first it was really hard to find developers > who > > where willing to agree to do the work. And then there was a huge amount > of > > infighting. > > > > The problem is there is not a mindset of "this makes sense", "lets do > it" but > > much more a mindset of bickering on whatevr the other did. > > > > Also various company executives could have encouranged the employees to > do > > maintaince work for FFmpeg STF. Would have cost them 0, would have made a > > huge difference in how many people would have been available! > > > > And about authority. > > We have some developers who want to have a say in everything. That just > takes > > all passion out for some people. I also think this was a big factor why > Paul forked > > > > So IMO, the mindset of the FFmpeg team needs to change. If one sees > another > > working on something lets say a booth or STF, or anything code related or > > anything code unrelated the idea would be to be supportive. <--- This > would help I belive > > > > The other change would be to draw clear lines and clearly give authority > to > > people in their area so they have some borders that shield them from > things > > that take their passion away. Which then makes them stop maintaining the > code > > and that then takes the passion of contributors away. > > > > Or maybe to put this another way. Try to have exactly 1 cook in every > kitchen > > If you intend to eat the resulting food. > > OMG a GSoC student is complaining about how hard the contribution > process is and you've turned it into "yet another Michael wall of > text" that has nothing to do with the topic but instead yet another > incoherent airing of your current grievances and the usual defence of > your buddies. > > It's clear the contribution method is outdated and difficult to > manage. We need to move to GitLab ASAP (the name Forgejo will put > people off, I mean seriously, Esperanto names in 2025, what a joke) > with proper CI. Otherwise people like the OP will be put off. I have > lots of people on the assembly course looking at the mailing list like > it's a fax machine. > > Kieran > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
