Skip to main content

Being part of the Engineering Team

About us​

The engineering team, also known as the development team, is the backbone of this community. This team is saturated with potent young talent who engage in various challenges when it comes to contribution. These contributions have helped shape not only the community, but also the individuals who partake in the development cycle. Once you are part of the development team, you will be subject to familiarization with cutting edge technology and the improvement of your attitude and general practices in regard to being part of the corporate culture. Although the team is commonly known as the development team, their tasks are not exclusive to the development phase. The construction of a new project heavily speaks for this, since the team is responsible for the likes of designing the architecture, development, testing, maintenance and further. The developers will always have something to take part of; whether it is a new feature, bug fix, or a new project in itself. Whichever the case may be, the community is more than happy to add a new developer to the roster.

Getting started​

Considering the frequency of volunteers pouring into this community, as well as the existing volunteers taking part in something completely new, it was observed that the community was in dire need of a handbook. It would not only be beneficial for someone looking to get started with their first contribution, but also to someone who has long forgotten how to officially send a ‘thank you’ message after merging a pull request. Following are a few prerequisites before you can be part of the community:

Creating a GitHub account​

All our projects are version controlled using the Github platform, and if you’re someone looking to contribute, it is essential for you to have a Github account of your own. What better to explain how to do that except for the official GitHub documentation itself.

Connecting on slack​

Slack has surely made communication in the corporate world better, and it has been no exception for our community as well. Even Though we use hive for major topic discussions, Slack is used by us for quick communication where time is in consideration. You can be part of the many group chats available, to raise questions and clear your doubts. Be part of the workplace

Creating a hive account​

Think of hive as a social platform, or a communication hub, which is exclusive for SEF members. We use this discourse group for a plethora of endeavors like introducing ourselves to one another, starting discussions about new features, bug fixes, and stand-ups, and even sharing memes. We got it all, and it is essential that you become part of this platform.

Introduce yourself​

The aforementioned ‘introducing yourself' is a big part of our community, and a separate thread is dedicated to this on the Hive. Although not mandatory, we highly encourage new members of the community to open up about themselves as a form of an ice breaker, so that not only the existing members get to know about you, but visitors as well.

  • Before you join development, please set up the project on your local machine, run it and go through the application thoroughly. Press on any button you can find and see where it leads to. Explore. (Don’t worry. Nothing will happen to the app or to you due to the exploring. The only thing that will happen is, that you’ll be more familiar with what is where and might even get a better idea on how to improve various aspects of the app.).
  • If you would like to work on an issue, drop in a comment at the issue. If it is already assigned to someone, but there is no sign of any work being done, please feel free to drop in a comment so that the issue can be assigned to you if the previous assignee is no longer working on it.
  • Newcomers are sometimes hesitant to make a pull request. Don’t be! It is the responsibility of reviewers to review them and Git is a beautiful tool when it comes to reverting pull requests containing errors.
  • When it comes to simple issues, keep it simple and just contribute, e.g. in an issue “change the color of the button from green to red”, there is no need to mention and ask “here is a screenshot where I changed the color to red. Should I make a PR now?”. Just make the pull request and wait for the feedback of the reviewer.
  • Take on responsibility early and help to review other contributions. Even though you do not have write access in a repository you can already help in reviewing other commits.

Development Best Practices​

Culture and Communication​

  • Please adapt your language to non-native English speakers and be super friendly. We are not used to swearing and will mostly understand words literally. At all times ensure your tone stays appropriate and friendly in the SEF community.
  • Stay modest. Sometimes newcomers already have excellent knowledge in some areas. Even the best developer is no master of everything, therefore there is no reason to be arrogant.
  • Be nice and welcoming. Why not add “please” in an issue or a comment, “Thank you” in a pull request if someone did a good job? Show your gratitude for the good work of your co-developers.
  • If you are involved in a topic you don’t understand yet, try to learn it by yourself as much as possible from public channels (Wikipedia, StackOverflow) but also do not hesitate to ask questions from other developers.
  • Currently, we use Slack as our communication channel. Join SEF Slack Channel. For more formal large scale communication threads, we use SEF hive.

Private and Public Chat or Issue Tracker​

Chat is a great way to connect with other contributors, but not all contributors are available all the time (consider time differences and personal schedules). Chat tends to be unstructured and with lots of people in a room, there are often a number of threads. Therefore chat is a great way to resolve issues on setting up projects and sort out blockers. Do not use chat for feature requests and detailed discussions on issues. These things are best done on the issue tracker, where people can join in and create a focused conversation on one specific topic. Some people try to overcome unstructured chats by switching to private communication. This shuts out other contributors who might have similar issues. A result I often observe is that contributors will bring up arguments in discussions like for example: “I have discussed this already with XYZ privately and he agrees”. Other contributors have not seen this discussion if it has not taken place in public and we haven’t seen the arguments. We don’t know if XYZ really agrees or if it was misunderstood. Private conversations are not transparent. Surely, there are cases where private chat is needed, e.g. for specific deployment questions of projects, but whenever you talk about development, please switch to public chat or open an issue.

Feature Requests and Bug Reports​

  • Some newcomers are not accustomed to issue trackers and might try to inform developers on the mailing list, chat or even write private emails about bugs and features, but the right place to do this is The issue tracker of a project.
  • For any bug or feature, please open an issue in the issue tracker right away and indicate if you want to work on it yourself. -Please include all relevant information when you submit an issue and wherever possible a link, information about the code that has issues, and a screenshot.
  • When you file a bug report on the issue tracker, make sure you add steps to reproduce it. Especially if that bug is a rare occurrence.

Commits/Pull Requests​

  • All pull requests need to be associated with an issue.
  • All PRs need to be assigned to the person working on them.
  • If an issue cannot be completed in less than a day, it should be broken up into multiple issues.
  • Make pull requests from your own forks (even if you have the ‘write’ rights to the repository, do not create new branches, instead develop on your own branches).
  • State the actual change or enhancement in the commit message of PRs (do not just state “Fixes issue #123”).
  • Add the issue number into the description (this helps to speed up reviews as reviewers can simply click to get more information on the issue itself).
  • Write clear meaningful git commit messages. Refer here.
  • Match pull requests with issues and make sure your pull requests description contains GitHub’s special keyword references that automatically close the related issue when the pull request is merged. More info here.
  • When you make very minor changes to a pull request of yours (like for example fixing a failing Travis build, some small style corrections or minor changes requested by reviewers) make sure you squash your commits afterward so that you don’t have an absurd number of commits for a very minor issue. Learn how to squash here.
  • Add a screenshot if you changed anything in the UI of a project. When you’re submitting a pull request for a UI-related issue, please add a screenshot of your change or a link to a deployment where it can be tested out along with your pull request. It makes the process easier for the reviewers and the review pending time gets reduced as well.
  • Add a link to your deployment of the project, where reviewers can check out what changes you have made (especially for smaller changes this is very helpful as the reviewer might not even need to set up the system itself and test it)
  • Always ensure CI and tests are successful.
  • Help to resolve merge conflicts (especially if there are several PRs at the same time, merge conflicts are common. Help the reviewers by solving the merge conflicts to speed up the process).
  • Pull Requests should only be merged if at least two contributors reviewed and approved it.

Scope of Issues and Commits​

  • Stay focused on the issue and its specifics: Sometimes it is tempting to do more changes in a pull request and simply add a nice little feature after mentioning it in the issue tracker. Please do not do this. Contributors will look at the title of issues usually to check if it is relevant to them. For example, if an issue is about changing a font, do not also change the color even if this seems like a small change to you. Many projects have a design template and standard colors etc. that they want to achieve. So your changes might need to be discussed in a bigger setting even if they seem small to you. The same applies to many other areas.
  • Do only the changes in a pull request that are mentioned in the issue. Do not change anything else without ever mentioning it (remember match issues with pull requests).

Branch Policies​

Most SEF Projects have:

  • A development branch (which is the working branch. Please commit to this branch.)
  • A master branch (which is the stable branch). Some projects also keep additional branches.
  • Pull requests should be made to the default branch.

Documentation​

  • Please ensure you provide information about your code and the functioning of your app as part of every code contribution.
  • Add information on technologies and the code into the code itself and into documentation files e.g. into the Readme.MD or /docs folder. Documentation is not a thing that should be done at the end after a few weeks or months of coding! Documentation is a continuous effort at every step of software development.
  • If you add new libraries or technologies add information about them into the Readme file.
  • If you implement a different design or change the CSS in a web project, please add information to the design specifications/template. If there are no other design specifications in the project yet, why not start them and add a section to the Readme.MD to start with?
  • Always help to keep documentation up to date and make it easy for new contributors to join the project.

Developer Hierarchy​

Our contributors are granted badges with each milestone. These achievements can be added to your linkedin profiles, and social media profiles. For further details refer here The hierarchy of badges and the requirements are as follows:

  • Level 0 - Contributor Kraken
    • Has made the first pull request
    • Has introduced themselves on SEF Hive
  • Level 1 - Titan Developer
    • Has made three pull requests
    • Has level 0 badge
  • Level 2 - Git Gojira
    • Has made five pull requests
    • Has level 1 badge
  • Level 3 - SEF Prodigy
    • Has passed the quiz
    • Has level 2 badge
    • Will be added to the GitHub organization
  • Level 4 - Monster Volunteer
    • Has taken part in standups for one month
    • Has level 3 badge
  • Level 5 - Open Source Behemoth
    • Is a member of a sprint
    • Has level 4 badge
    • Will be added to the engineering team as a software engineer

Weekly Engineering Team Standup​

Join us for our weekly Engineering Team Standup every Saturday at 7:00 pm IST. Meeting Link: https://meet.google.com/mys-fenp-knv