Are there any particular separate channels for GSOC?

I have noticed no feedback or replies on my previous posts mentioning GSoC are there some other forum or slack channel specifically for GSoC idea list discussion, just wondering?

But you’ve gotten feedback a number of times. Please pay attention to this post again:

Yes sorry, my bad. I think what I was asking for specifically like are there specific channels for discussing specific ideas from the idea list :sweat_smile:

Well, if you think that a GSOC is this, you are probably mistaken. If you were taking a look at the backlog of uncared for Pull request (and yet many of them quite interesting) for the jitsi-meet project, you’d understand that the would-be tutors are swamped by their work and are unlikely to baby sit would be students. If you show you can swim, they will get really interested in helping you.

Think about the project you picked, search the net for references on the subject, read them and try to understand them and try to do a plan. If you come up with something, post it here for advice. Don’t be afraid a competitor will steal it, if you are the first to post it Jitsi-meet devs will notice it.

And then the hard part, try to explore the Jitsi-meet source code as it’s necessary for most of the project I think.

My 0.000002 cents about it: as I understand it (I may be wrong of course I was not born when the project began :-)): Jitsi-meet started as a Java project for a personal telephony application (it’s called Jitsi desktop vs Jitsi-meet). A long time ago devs thought that a web app could be the way to success and developed a server based on this Java code. As a web part was necessary, a Javascript app was born. At first it used JQuery. And then they saw the React light (JQuery was not much of a help to deal with phones).

There is still scars of this time, that’s why there is a subdirectory react in the tree. Why is there this subdirectory if Jiitsi-meet is a React application ? because Jitsi-meet has still not - years after - completely migrated to React, there is still the modules directory where are living the JQuery artifacts (particularly the UI subdir). If you deal with Jitsi-meet you have to be able to master this particular setup. And of course devs are not keen on documenting this since it would make permanent something they are probably not liking very much, but real world software has many many urgent tasks and cleaning the code for a big project is always something you have to do - at some time in the future. And they are not motivated to document because it’s not ready. That’s why software architecture is a subject you will struggle to find good information on the Jitsi-meet project (the javascript part at least).

Show that you are able to understand this thing and post a pull-request to fix a small problem in Jitsi-meet Javascript code and your acceptation will be likely. That’s a totally personal speculation from someone without any link to the project, so it’s either fully objective or utterly mistaken :wink:

Thanks. This makes sense to me .
find doubts=> scour the internet=> try to understand what is what => ask mentors specifics if doubt still persist.

The dev part was really good advice.

I don’t see other potential contributors as competition but I get what you mean : )

So basically the objective of jitsi devs right now is to make the transition to JS / React / RN / Cross Platform application smoothly and add additional features ?

Yeah makes sense someone who already understands and improves upon the existing code base can also contribute to projects more easily .

Thanks for your valuable advice and minor reality check. I am taking this advice as fully objective for now lol.

It’s largely done, as I said there are still relics of the old code and it’s probably difficult to clean this code. IIRC I have found somewhere in the code some comment about this upgrade and git log said it was from years ago so it’s a long term enterprise. In the mean time devs are struggling to keep up with new features, new security advices, new (and incompatible) library versions, and many other things.

That is definitely going to be a challenge even if you code for cross-platform there is need for native mobile developers for a multitude of reasons.

Yeah I noticed the thing about library versions in this PR that I created here a whole new dependency had to be installed to update like 3 dev Deps to resolve a compatibility error. I imagine doing that for multiple repos with multiple packages would be a hassle.

Ah yes, did I say that the project direction is to manage everything in react native but there is the need (for practical reasons of making things work actually) to have separate code for native and web ? You will need to be able to test your code on Android (at least) and possibly on IOS.

Yes, thanks for the advice. I thought so too, mobile compatibility has to be taken specific care for, in the possible-ideas post docs I am currently making here.

I will keep Android and IOS mobile platforms compatibility (IOS a bit more, particularly imo) in mind: )

Coming back to the library updates/configurations issues I would say we can add some labels which will accelerate the process. of new contributors making it easier for them to start working on the dependencies/libraries issues because we will need some people updating libraries and making the packages compatible with dev and production builds at regular intervals, as and when appropriate. I think I had opened that issue here.

your thoughts?

my thoughts are that Jitsi devs are - as most I think - very conservative on keeping all dependencies pinned to specific versions and don’t upgrade unless there is a specific need (security consideration - and I think that even here security problems have to actually impact the project - or unmaintained library or blocking bug). Rationale is probably that library breakages are a fact of life and each upgrade should be regression tested. If your dependency upgrade fixes an existing bug while not creating any new one, I’m sure it will be very welcome though.

1 Like

I agree.

Thanks for your feedback : )