This was a meaningful week. It makes me use different perspectives to think about some stuff.
We had our first triage meeting for the telescope project(I was wrong in my last post, what we had in the last week was just intro meetings). The process was not as difficult as I thought. It is well organized and handled, pretty easy to understand for new team members. However, I still wasn't active enough. The reason is mainly because I don't have enough knowledge to join the discussion when it comes to certain topics or questions that require some professional knowledge. When I thought I've already spent a significant amount of time on new (new to me) tools (e.g. nextjs, typescript) of telescope, and was able to review some PRs and take over one, I still can't quite understand all the content in the meeting.
In this week's release (1.5), our main goal is to move most of our components from Gatsby to Nextjs. Nextjs is a totally new stuff to me, so does typescript (I knew it but never write it by myself). My strategy was reading Nextjs' documentation and the closed PRs about porting to Nextjs at the same time. This is a bit like cheating, like walking a maze from the goal to the entrance. This does help me to work through this week's release which is mainly about porting to Nextjs, however, I can't really tell and organize what I've learned from them. I'll need to figure it out how to learn new tools and apply them at the same time. (Or, I can just take more attention on these new tools... in general)
Another thing I want to talk about is the waiting rules in an open source project. When members are assigned a couple of tasks, but couldn't finish it before the release day, and couldn't get in touch with the assignees. Honestly, I don't want to wait and postpone the release date or move these tasks to the next release. I may not be a smart developer, but I love rules and deadlines and respect them. When we're working as a team, we should always respect other people's time. It is sort of irresponsible for the situation like this. However, it's really hard to say or do something strict in a team since no one wants to be a bad guy. In this case, having a clear protocol of asking team members to follow the schedule and also inform the penalty (although I can't think of any appropriate and effective penalty in an open-source project) might be a good choice. Another alternative is to keep in touch with assignees frequently, therefore, we can control the possible damage on time. However, if the assignee doesn't like to text, it might not work well.
After the PR I made this week and a React app project that I am doing in another course, it's more positive that I should spend more time on the front-end JavaScript libraries. This field is extremely flexible, and I'm apparently not fast and adoptable enough to it.
Top comments (0)