The planning process is an open source project is often created and monitored by the maintainers. This blog intends to go over the commonalities found by Safia Abdalla in open source planning mentioned in her article “Open source excursion: The poetry of planning”. I chose this topic because it relates to both the section in class where we went over licensing, which included open source licenses, and the section where we over different planning philosophies like scrum.

The first shared tendency between open source maintainers Abdalla lists planning with the intent to build excitement in the community that might hold many of your future contributors. Maximizing the outreach your plan gets among possible contributors and consistently providing updates when changes are made attracts attention towards your project, increases your chances of acquiring new contributors, and encourages existing contributors. Another common planning practice Abdalla lists is planning to prioritize. This planning method aims to optimize the process by which user requests and pull requests are fulfilled by distributing the responsibility among a chosen team. This allows for the efficient processing of requests, as well as allows many members of the team to get well acquainted with the user community and their hopes for the team’s project. The last 2 planning methods listed by Abdalla are planning to communicate and planning incrementally. Planning to communicate is a method of planning that, once a projects priorities and goals are well defined, aims to communicate those goals with the community. This leads to more exposure for the project, and possibly more support and contributions to it as well. Planning incrementally is a planning method where members of a team are mindful of the dynamic nature of the planning process, and communicate to the communities interested in the project the same thing, as to not mislead them.

Overall, these commonalities between open source planning all seem like good habits, and practices that would be useful for me to employ as a future open source project maintainer, and would also be useful as a contributor to open source projects to be aware of these tendencies so I can better align my work to the maintainers’ planning strategies. Planning with the intent to build excitement, along with being an effective planning strategy, sounds like it would also help for beginner developers to build a presence for themselves in the communities that are interested in the project that’s employing it.

https://increment.com/planning/open-source-planning/

Link to source blog:

From the blog CS@Worcester – My first blog by Michael and used with permission of the author. All other rights reserved by the author.

Code visibility or the lack of it can introduce many problems that hinder the development process of a project. Some problems that can stem from poor code visibility include the misunderstanding of the function of the code or large portions of it, not defining possible conflicts well enough to avoid future features including them, and generally consuming an unnecessary amount of time. In Allison Wheeler’s blog, “Maximizing developer productivity with code visibility: A Complete Guide”, Wheeler goes over some other possible complications that could arise from poor code visibility, and presents tools like GitKraken as solutions to those complications. I chose this topic as it relates to the importance of clean code and other coding conventions we covered in class.

Wheeler presents the problems of poor code visibility as 3 main points; Lengthy prep time, Risk of conflicts or redundant code, and slow bottlenecked code reviews. The issue of length prep time arises when the function of the code or portions of it isn’t clearly stated and is left to the developer to figure out via time consuming methods, like trial and error. The issue the risk of conflicts or redundant code is related to the previous issue, where, because of time constraints and poor code visibility, the developer has an incomplete understanding of the code’s function, therefore not seeing how an added feature would be redundant or introduce a conflict. The issue of slow bottlenecked code reviews is also related to the misunderstanding of the code function, as when quality tests are conducted to test a change, a misunderstanding of the function of the unchanged code will result in an inaccurate quality test related to a new change. A solution to these problems is presented by Wheeler in the GitKraken DevEx platform, which is a technology with the aim of making the codebase of a project more accessible and decipherable.

Some of the features that improve code visibility include the creation of workspaces, which forgo the need for newly onboarded developers to access repos through the directory and organize all relevant repos in a single space. This removes possible confusion new hires could have with which repo to commit to. Another feature that improves code visibility is the launchpad feature, which organizes inter-repo requests, like merge, push and pull requests, into one space for the user to view. This feature allows developers to see which issues are being worked on and where the progress of the fixes for these issues are.

I can already tell that this information will be useful to me in my professional career, as many of these features resemble those that were in gitpod as we used it in class. Platforms like these seem very useful for streamlining the development process.

Link to source blog:

From the blog CS@Worcester – My first blog by Michael and used with permission of the author. All other rights reserved by the author.

For my first blog I decided to talk about how individual contributors can best fulfill their role in the process of developing a project. This is relevant to the course material because the role of an individual contributor, which is mostly to improve the code and coordinating teams of other ICs, is a similar role the members of a development team would have in sprint.

The position that ICs occupy in most projects is a very impactful and influential position, aside from their ability to directly change the code. Despite their limited access to the management side of most projects, their proximity to the code gives them unique perspectives on the possible directions project could take, and what is and isn’t feasible to implement. In David Noel-Romas’ blog “An ICs guide to roadmap planning”, he introduces the problem of the IC who wishes they had comparable influence to the planning process of the project to their influence on the state of the code. Romas’ suggests several solutions to this problem, including identifying stakeholders and planning around the potential impacts the project will have on them through feedback and other means, making sure the management end of the team is aware of your visions for the project and when would be the most convenient times deliver updates and new features, and rationally bounding the work your team can do in the given amount of time, making an effort budget and working according to it. I think these solutions all take care of the problem of an IC who feels they aren’t offering enough input to the planning process well, and do so in a manner where the team dynamic isn’t compromised.

One of the reasons I think these solutions are effective is because they lend themselves well to the team structure of popular development philosophies. For example, if a development team is using scrum, there are points in the development process where an IC and their team can convene with the rest of the team members, like the sprint review, and offer their opinion on the direction and feasibility of the changes desired by other members of the team. The sprint review also allows the ICs to communicate with shareholders and assess. Since there are multiple sprint reviews per project, this allows many chances for an IC to offer their opinion on the planning process.

I can definitely see where this information will be useful in my professional career, as development philosophies like scrum are commonly used, and the input of an IC in the planning process can be essential to delivering a well made product.

Link to source blog: https://increment.com/planning/individual-contributors-guide-to-roadmap-planning/

From the blog CS@Worcester – My first blog by Michael and used with permission of the author. All other rights reserved by the author.