Some advices for a first timer? I'm considering sending a proposal to strace but I'm reading some part of the source code, (git-blaming around) but I don't think I understand it enough to modify it ...
When have you ever seen a complex, in-production software system and immediately thought “yeah I get this!”?
If you’re anything like me, you’ll have this feeling on every new project and new job you start for a while. I’m in my late thirties and am finally starting to realize that “hey, I have this feeling a lot and it’s always wrong.”
Push through it. Write the proposal. I think the proposal-writing process is the very best aspect of GSoC since it forces you into something that you really don’t tend to do in traditional learning like universities. It forces you to think a bit like a product person even and explain benefits and tradeoffs, backing up your beliefs.
(a) As others have mentioned, it's entirely normal to initially feel like one doesn't understand a new code-base of non-trivial size enough to modify it. One of the skills that participating in a programme like GSoC can provide is learning the tools & strategies that you can use to assist in growing your understanding of new code bases.[1]
(b) From an outside perspective, the fact you're aware of the existence of `strace`, have an interest in contributing to the project & have already poked around in the source code in an attempt to understand it are big positive indicators & differentiate you.
(c) That you're using a tool like `git blame` to assist in your exploration indicates that you've already learned some of the tools/strategies you can use which is also a positive. (As an aside, today I learned about the tool `git-dive` which is intended to be a more powerful form of `git blame`, you might be interested in checking it out: <https://github.com/gitext-rs/git-dive>)
(d) Also, with regard to `strace` specifically, you might gain some insight from this recent video: "strace feels like magic — let's fix that (with Rust)" <https://www.youtube.com/watch?v=engduNoI6DE>. While the video uses Rust for the implementation it also provides a general overview of how `strace` works. (This might be a useful intro to Rust syntax, if you're not currently familiar: <https://fasterthanli.me/articles/a-half-hour-to-learn-rust> (BTW, it is also extremely normal to not understand everything/anything about Rust code on first sight. :) ))
(e) Personally, in the past I've found it extremely easy to talk myself out of submitting proposals for opportunities such as this but my current perspective is: if I have doubts about whether or not I'm experienced/qualified enough to submit a proposal then I'm definitely not qualified to evaluate whether I should submit a proposal--so I definitely should submit a proposal to give those who are qualified the opportunity to evaluate it. (After all, if you don't currently maintain the `strace` project you have no idea what their experience has taught them is important in order for people to successfully contribute.)
Hope some of that is useful.
[0] re: "advices" -- in this context, "advice" is the preferred word[2]. I mention this as written communication is important & based on your previous HN comments this seems to be a pattern of incorrect pluralization rather than a typo. Note: I do not have perfect grammar. :)
[1] Also, I would encourage you to take notes of what you don't understand or issues you ran into when you start exploring a project. You can then document these hurdles/barriers to new contributors for the project so that maintainers are (at least) aware of them. This is one situation where your relative inexperience with a project is in itself valuable because your perspective is one maintainers no longer have. (And such hurdles are important to identify for projects that are actively looking to attract & nurture new contributors.)
If you’re anything like me, you’ll have this feeling on every new project and new job you start for a while. I’m in my late thirties and am finally starting to realize that “hey, I have this feeling a lot and it’s always wrong.”
Push through it. Write the proposal. I think the proposal-writing process is the very best aspect of GSoC since it forces you into something that you really don’t tend to do in traditional learning like universities. It forces you to think a bit like a product person even and explain benefits and tradeoffs, backing up your beliefs.