The following lab delves deep into two open source software with a unique license and agenda of their own. This lab will dissect the review process in detail, as well as a thorough insight on everything that goes behind the scenes when a patch takes place.
1. Kodi -
https://github.com/xbmc/xbmc/blob/master/LICENSE.md
https://github.com/xbmc/xbmc/commits/master
https://github.com/xbmc/xbmc/pulls
https://github.com/xbmc/xbmc/graphs/contributors
Out of the many popular open source projects that currently exist, Kodi was something that caught my attention. Licensed by GPLv2, this particular software facilitates creation of set-top boxes across different platforms; hence putting an emphasis on its ability to customize with ease. In my opinion, the review process in this particular situation goes on to take more than one forms. With GitHub extensively being at the forefront of the way Kodi's source code operates, the review is broken down into many features. Pull Requests for instance, allow fellow contributors to know about the changes made by you. If everything is deemed okay with the consent of experts and collaborators, your changes will eventually reflect the final outcome as they get merged with the base branch. This methodology is adopted by Kodi in an attempt to continuously seek efficient results. The iterative nature of this review process is what makes it so well maintained. Consequently, everyone is on the same page and knows the direction that they're going in. These can eventually be tracked in the "commits" section of the page. Alongside this, the "contributors" section gives a cursory summary of all those that have offered their inputs one way or another. The status of the any pulls/merges can be recorded in the "insights" section, which continuously updates the team with every new step. Similar to github, this also has a contributors section: https://gitlab.com/freecad/FreeCAD/-/graphs/master
To summarize, it can be said that the review is broken down into different sections; Pull Requests which, upon approval, can be merged in continuously after feedback has been provided. This is further emphasized upon when every contributor provides an insight on what should be included/ discarded. Attached below is one such instance of one single pull request which goes by the same ideology as discussed above (a cohesive iterative discussion eventually building to the final outcome)
Advantages - really inclusive and ensures the entire team is participating
Disadvantages - can get really congested and hence, difficult to deal with the incoming traffic
What I would do differently - perhaps have a separate location/ folder for patches and provide a template for every patch which comprehensively outlines what every patch is meant to achieve and who is responsible for it; keeping everyone in the loop simultaneously. People can eventually provide their feedback on the comments section before giving it a thumbs up.
https://github.com/xbmc/xbmc/pull/17112
2. FreeCAD
https://github.com/FreeCAD/FreeCAD
https://www.freecadweb.org/
https://gitlab.com/freecad/FreeCAD
https://www.facebook.com/FreeCAD
FreeCAD too, follows a similar ideology as Kodi. Licensed by LGPL, This particular software is written in python and emphasizes on the concept of parametric modeling, wherein real life 3D objects can be created on the spot, irrespective of the size and the nature of the object. As far as the review process is concerned, its community spreads across a multitude of platforms with Facebook GitHub and GitLab just to name a few. Putting GitLab into perspective, it has a very similar framework compared to GithHub, except that the emphasis is more on commits. Every activity is logged in the 'review' section, with a bunch of contributors providing their inputs on it on a frequent basis. Attached below is one such instance of a single commit: https://gitlab.com/freecad/FreeCAD/commit/e7796c04979d75056fb34a3574a28c733b1b6f8c
There is comprehensive emphasis on the status, as well as the code section under scrutiny. This is one small aspect of the review process. Looking at the bigger picture, everything is facilitated by the commits made, with each having a unique identifier of their own.
Also, another good aspect of GitLab is the "charts" section : https://gitlab.com/freecad/FreeCAD/-/graphs/master/charts
This gives onlookers a breakdown of every necessary detail (in this case, the proportion of every programming language used).
Advantages - the multitude of features used makes it so environment friendly and easily accessible; not all platforms have features as diverse as these (shout out to GitLab for helping facilitate that review process)
Disadvantage - Again, can be cluttered with tons on unfinished tasks, can pile pressure on the contributor and can make it a nightmare to deal with. Also, there's too many unnecessary sub sections in the menu which can take up time when it comes to navigating.
Alternative - There can be a single page consisting all the patching information. I would initiate an idea for a patch, see how my fellow contributors respond to it, eventually go on to execute it and then the occasional back and forth before its finally merged. In such cases, it would be useful to VERSION such patches. Keep updating various communities with the recently made patch so that every community is in tune with one another.
1. Kodi -
https://github.com/xbmc/xbmc/blob/master/LICENSE.md
https://github.com/xbmc/xbmc/commits/master
https://github.com/xbmc/xbmc/pulls
https://github.com/xbmc/xbmc/graphs/contributors
Out of the many popular open source projects that currently exist, Kodi was something that caught my attention. Licensed by GPLv2, this particular software facilitates creation of set-top boxes across different platforms; hence putting an emphasis on its ability to customize with ease. In my opinion, the review process in this particular situation goes on to take more than one forms. With GitHub extensively being at the forefront of the way Kodi's source code operates, the review is broken down into many features. Pull Requests for instance, allow fellow contributors to know about the changes made by you. If everything is deemed okay with the consent of experts and collaborators, your changes will eventually reflect the final outcome as they get merged with the base branch. This methodology is adopted by Kodi in an attempt to continuously seek efficient results. The iterative nature of this review process is what makes it so well maintained. Consequently, everyone is on the same page and knows the direction that they're going in. These can eventually be tracked in the "commits" section of the page. Alongside this, the "contributors" section gives a cursory summary of all those that have offered their inputs one way or another. The status of the any pulls/merges can be recorded in the "insights" section, which continuously updates the team with every new step. Similar to github, this also has a contributors section: https://gitlab.com/freecad/FreeCAD/-/graphs/master
To summarize, it can be said that the review is broken down into different sections; Pull Requests which, upon approval, can be merged in continuously after feedback has been provided. This is further emphasized upon when every contributor provides an insight on what should be included/ discarded. Attached below is one such instance of one single pull request which goes by the same ideology as discussed above (a cohesive iterative discussion eventually building to the final outcome)
Advantages - really inclusive and ensures the entire team is participating
Disadvantages - can get really congested and hence, difficult to deal with the incoming traffic
What I would do differently - perhaps have a separate location/ folder for patches and provide a template for every patch which comprehensively outlines what every patch is meant to achieve and who is responsible for it; keeping everyone in the loop simultaneously. People can eventually provide their feedback on the comments section before giving it a thumbs up.
https://github.com/xbmc/xbmc/pull/17112
2. FreeCAD
https://github.com/FreeCAD/FreeCAD
https://www.freecadweb.org/
https://gitlab.com/freecad/FreeCAD
https://www.facebook.com/FreeCAD
FreeCAD too, follows a similar ideology as Kodi. Licensed by LGPL, This particular software is written in python and emphasizes on the concept of parametric modeling, wherein real life 3D objects can be created on the spot, irrespective of the size and the nature of the object. As far as the review process is concerned, its community spreads across a multitude of platforms with Facebook GitHub and GitLab just to name a few. Putting GitLab into perspective, it has a very similar framework compared to GithHub, except that the emphasis is more on commits. Every activity is logged in the 'review' section, with a bunch of contributors providing their inputs on it on a frequent basis. Attached below is one such instance of a single commit: https://gitlab.com/freecad/FreeCAD/commit/e7796c04979d75056fb34a3574a28c733b1b6f8c
There is comprehensive emphasis on the status, as well as the code section under scrutiny. This is one small aspect of the review process. Looking at the bigger picture, everything is facilitated by the commits made, with each having a unique identifier of their own.
Also, another good aspect of GitLab is the "charts" section : https://gitlab.com/freecad/FreeCAD/-/graphs/master/charts
This gives onlookers a breakdown of every necessary detail (in this case, the proportion of every programming language used).
Advantages - the multitude of features used makes it so environment friendly and easily accessible; not all platforms have features as diverse as these (shout out to GitLab for helping facilitate that review process)
Disadvantage - Again, can be cluttered with tons on unfinished tasks, can pile pressure on the contributor and can make it a nightmare to deal with. Also, there's too many unnecessary sub sections in the menu which can take up time when it comes to navigating.
Alternative - There can be a single page consisting all the patching information. I would initiate an idea for a patch, see how my fellow contributors respond to it, eventually go on to execute it and then the occasional back and forth before its finally merged. In such cases, it would be useful to VERSION such patches. Keep updating various communities with the recently made patch so that every community is in tune with one another.
