Social Coding Collaboration and Flowing Your Work Different
BEFORE you even get started …
You should be at least passingly familiar with the architecture of older open source applications … because it’s kind of necessary to understand something about how/why things developed as the did, what worked and survived … and you won’t ever know about all of the attempts that didn’t survive … although there are millions of open source development efforts out there now that will never survive, because developers without experience tend THINK they know exactly how open source development communities should work. BEFORE you even get started, especially if you are an grizzled veteran who has all kinds of experience in programming on your own, which makes your experience largely irrelevant because that experience was just you and your computer WITHOUT the social interaction of a development community, spend some time learning the very most basic of the basic fundamentals of how open source development communities actually work. It’s about the CULTURE, not the technology.
As you go forward in contributing to open source projects, you will run into great communities and you will run into completely dysfunctional communities and software development organizations that are not really going to be going anywhere. You might also encounter a few communities that grew up around an open source piece of software which came of age BEFORE open development processes and social development workflows … Bash is an example of GREAT, justifiably immortal, definitively useful piece of open source software, but Bash has an open source development process that has never been aggressively or evangelically open, although Chet Ramey, the main maintainer for decades never deliberately closed off that development process to others … it’s just that Bash was developed in the 1990s and bash exists because of Chet and really pretty much Chet alone … even though, a lone developer still depends upon feedback from the audience of patient beta users. So Chet used what worked best for him at the time, sort of defining the best way to do it as he went along [by necessity, ie that’s the only way it could be done] and he gradually become comfortable with the idea of milestone releases (e.g., bash-4.2) and individually-released patches to accommodate vendors with longer release timelines than the free software and open source world although this caused issues with beta-level software to proliferate through sharing and become more widespread among a general anxious-for-the-latest-features audience than Chet intended for the beta-level release. As Chet says, if he were starting over again now, though, he’d use a workflow that reliably produced much more frequent releases, using some kind of public repository with a modern open source community.
This does not just mean that if your organization has four separate groups working on a compiler, that organization structure will tend to produce a four-compartment compiler or one that compiles according to some sort of 4-pass strategy … although that pithy example is essentially correct and definintely simple model that help people to open their eyes, rather than taking the way they’ve always done things for granted and get heads wrapped around how a developmental workflow will drive the fundamental architecture of something.
The inescapable nature of human organizations drives natural human cognitive tendency to structure thought according to shared language and shared ways of operating within a defacto system … so an inner platform effect tends to hardwire thought patterns … sinces humans NECESSARILY cannot escape designing systems which are templated layers or copies of the communication structures and foundational workflows used in the communities or organizations which design things. Human beings are generally not capable of achieving something telepathic like a vulcan mind melds … when we imagine that we are thinking alike with someone else, we are mostly imagining that. Humans must cognitively form representations of ideas, express ideas semiotically with shared symbols, using semantics and linguistics that makes feel comfortable with one another … it is this essentially cognitive framework of workflows that dictates why social coding collaboration workflow will become the inner skeletal foundation of everything that a development community builds. Human language is CULTURAL … not technical … not just a bunch of words … or an AI-voice pronouncing someone else’s words …it’s a way of thinking and a way of thinking DIVERSLY in way that is somewhat shared by a group of people but MOSTLY humbly respected and consciousously diversified by a group of people who recognize that they do not exactly think alike but fundamentally VALUE and RESPECT the differences in their thinking because of the extra value created.
It’s worth spending a LOT of time getting this right.
We’re all in favor of social coding and collaboration … it’s like how everyone thinks standards and standardization are a great idea … we’re all in favor of standardization as long everyone standardizes on doing it our way. Social coding is beyond being just HARD or frustrating … troubleshooting something ON OUR OWN is a little bit hard or a little bit frustrating in comparison to how MASSIVELY HARD or MASSIVELY FRUSTRATING something is in a group of strong-minded, creative developers. Collaboration on something that really matters, ie where the output will be greater than the sum of it’s parts or the development is more than the sum of the individual developers. This is CULTURAL … not, is much more than intensely frustrating that dev’ing something alone.
It’s worth spending a LOT of time getting this right … so go back and spend some more time getting familiar with what has worked in the architecture of open source applications. It’s safe to say you probably should find yourself wanting to USE the fundamentals that your find those open source applications as part of the architecture of your own development workflow … instead of just mere gists of ideas, you might even use something like Git or the Bourne-Again SHell, more or less in its full entirety.
To START OFF …
It’s terribly important to get really, really familiar with the lay of the land first … FORK the repo and install it so that it works, get familiar with code by tweaking a few things, get up to speed on the discussions, read the documentation, go over the wiki, follow the threads on mailing lists, discord/slack channel … in order to be taken anywhere close to seriously, it’s really essential to really put in the work before asking too many questions … HOWEVER … ultimately, you will have to pipe up and just expose yourself as an idiot with a stupid question.
And that’s when the fun starts … becuase there are no stupid questions is more than just a trite cliche … QUESTIONS and discussions are absolutely essential for social coding … if you really tried to prepare and then were abused because of your dumb question – then maybe the group is not for you.
It is painfully humiliating to THINK that you understood what’s going on … and then you find out that you THOUGHT you understood, and told people that you thought you understood … but you actually understood something ever so slightly different than Reality as Reality REALLY was.
This happens. This is why we never judge others … we USUALLY do not have a clue about how other people think … but we often really believe that other people see things just like we do … different people approach things like the SOCIAL nature of coding in a different manner … and if you were not welcomed for honestly trying to contribute, then maybe the group is not for you. There are plenty of other fish in the sea.
In GitHub or Gitlab, contribution typically starts by forking own personal copy of the original repository, then taking that fork and cloning it locally to your own machine … and playing with a bit, and pushing one or more commits back to that personal fork BUT BY THEN YOUR FORK IS NOT EQUAL TO THE ORIGINAL FORK IN THE ORIGINAL REPOSITORY. To be successful with this approach, your really have to WORK AT STAYING IN SYCNCH, really understanding the CURRENT mindset of the people who are developing the code today FROM THEIR POINT OF VIEW … you have to SYNCH YOUR MIND to the community’s mind … once your little improvement to the code seems ready to merge, you can ask the service to create a pull request in GitHub or a merge request in GitLab for your branch into the original repository. The request will be reviewed, and since it’s difficult to stay in synch, there will need to be lots of back-and-forth to make really sure all of the people are on the same page … if everything appears to be in synch and if accepted your changes get merged into the original repository, then the real fun starts.
In contrast to Github or Gitlab, OpenDev is a collaboratory for open source software development at scale. Its focus is more heavily on on the code review side … it’s more about larger team continuous integration … not just integration of the code or git data, but INTEGRATION of the minds working on the project. The project hosting for OpenDev projects will provided exclusively through open source solutions like Git, Gerrit, Zuul, and Gitea. OpenDev also provides a number of peripheral collaboration services most notably the Mailman GNU mailing list manager. OpenDev doesn’t use a pull request (or merge request) workflow, like those implemented by GitHub or Gitlab. Instead it follows Gerrit’s iterative change proposal workflow, which results in a slightly different experience, since contribution with Gerrit starts by cloning the original repository locally and then always working together on the a similar clone of the same ORIGINAL reference repository, rather than a forking and work on forks.
It cannot be emphasized enough that the whole development process is usually centered around the issue-driven pull request in GitHub or issue-driven merge request creation in Gitlab … and your best chance of making contribution and earning some cred is to really, Really, REALLY understand the issues in issue tracker and the pull/merge request process and, ideally, to WORK ON SOMEBODY ELSE’S ISSUE.
Before you submit your first issue
Really, really, REALLY search the issue tracker for similar entries* … maybe under a different title or with different wording. Someone else might have already had the same bug or feature proposal. If you find an existing issue that is tied to the bug you’ve found or feature that you’re proposing, show your support with a simple emoji emotional reaction for how you feel about the issue … then, if needed, add your specific technical notes/comments/concerns/suggestions/questions to the issue discussion.
If not, which might be more likely for your early contributions since you’re still figuring out how or why things were done, you push more commits to your fork and update the request seeking more reviews … there’s nothing wrong with just working on your own fork and using it as a way to really learn the code base and the community’s mindset IN A WAY THAT DOESN’T BOTHER ANYONE … but if you want to get your changes merged into the original repository, you’ll need to get the community to review your changes and to agree with your thinking and accept it. Do not underestimate how difficult and HUMBLING this can be … it’s not just about the code, it’s about the people and the essence of what it means to really BELONG inside a development community.