Community

Resolving Internal Error on Badgeyay

Badgeyay is in development stage and is frequently seen to encounter bugs. One such bug is the Internal Server Error in Badgeyay.

What was the bug?

The bug was with the badge generator’s backend code. The generator was trying to server the zip file that was not present. After going through the log I noticed that it was because a folder was missing from Badgeyay’s directory.

 

I immediately filed an issue #58 which stated the bug and how could it be resolved. After being assigned to the issue I did my work and created a Pull Request that was merged soon.

The Pull Request can be found here.

Resolving the bug

With the help of extensive error management and proper code and log analysis I was able to figure out a fix for this bug. It was in-fact due to a missing folder that was deleted by a subsequent code during zipfile/pdf generation. It was supposed to be recreated every time it was deleted. I quickly designed a function that solved this error for future usage of Badgeyay.

 

How was it resolved?

First I started by checking if the “BADGES_FOLDER” was not present. And if it was not present then the folder was created using the commands below

 

if not os.path.exists(BADGES_FOLDER):

    os.mkdir(BADGES_FOLDER)

 

Then, I added docstring to the remaining part of the code. It was used to empty all the files and folder inside the “BADGES_FOLDER”. We could have to delete two things, a folder or a file.

So proper instructions are added to handle file deletion and folder deletion.

 

for file in os.listdir(BADGES_FOLDER):

    file_path = os.path.join(BADGES_FOLDER, file)

    try:

        if os.path.isfile(file_path):

            os.unlink(file_path)

        elif os.path.isdir(file_path):

            shutil.rmtree(file_path)

    except Exception:

        traceback.print_exc()

 

Here “os.unlink” is a function that is used to delete a file. And “shutil.rmtree” is a function that deletes the whole folder at once. It is similar to “sudo rm -rf /directory”. Proper error handling is done as well to ensure stability of program as well.

Challenges

There were many problems that I had to face during this bug.

  • It was my first time solving a bug, so I was nervous.
  • I had no knowledge about “shutil” library.
  • I was a new-comer.

But I took these problems as challenges and was able to fix this bug that caused the INTERNAL SERVER ERROR : 500 .

Resources

 

 

Continue ReadingResolving Internal Error on Badgeyay
Read more about the article Auto Deployment of Pull Requests on Susper using Surge Technology

Auto Deployment of Pull Requests on Susper using Surge Technology

Susper is being improved every day. Following every best practice in the organization, each pull request includes a working demo link of the fix. Currently, the demo link for Susper can be generated by using GitHub pages by running these simple commands – ng build and npm run deploy. Sometimes this process on slow-internet connectivity takes up to 30 mins to generate a working demo link of the fix.

Surge is the technology which publishes or generates the static web-page demo link, which makes it easier for the developer to deploy their web-app. There are a lot of benefits of using surge over generating demo link using GitHub pages:

  • As soon as the pull request passes Travis CI, the deployment link is generated. It has been set up as such, no extra terminal commands will be required.
  • Faster loading compared to deployment link is generated using GitHub pages.

Surge can be used to deploy only static web pages. Static web pages mean websites that contain fixed contents.

To implement the feature of auto-deployment of pull request using surge, one can follow up these steps:

  • Create a pr_deploy.sh file which will be executed during Travis CI testing.
  • The pr_deploy.sh file can be executed after success i.e. when Travis CI passes by using command bash pr_deploy.sh.

The pr_deploy.sh file for Susper looks like this:

#!/usr/bin/env bash
if [ “$TRAVIS_PULL_REQUEST” == “false” ]; then
echo “Not a PR. Skipping surge deployment.”
exit 0
fi
angular build production

npm i -g surge

export SURGE_LOGIN=test@example.co.in
# Token of a dummy account
export SURGE_TOKEN=d1c28a7a75967cc2b4c852cca0d12206

export DEPLOY_DOMAIN=https://pr-${TRAVIS_PULL_REQUEST}-fossasia-susper.surge.sh
surge —project ./dist —domain $DEPLOY_DOMAIN;

 

Once pr_deploy.sh file has been created, execute the file in the travis.yml by using command bash pr_deploy.sh.

In this way, we have integrated the surge technology for auto-deployment of the pull requests in Susper.

References:

Continue ReadingAuto Deployment of Pull Requests on Susper using Surge Technology
Read more about the article How to organise a successful Google Code-In meetup

How to organise a successful Google Code-In meetup

In this blog post I hope to write about what is Google Code-In and the best way to organise a successful Google Code-In meetup or workshop in your local community. I hope you will find everything that you need to know about conducting a successful meetup.

What is Google Code-In ?

Google Code-In is a global and an open source contest funded by Google to give real world software development experience to pre-university students who are in age range 13-17. Beside of software developing, this contest’s main objective is to motivate tech enthusiastic students to contribute to opensource and give them the knowledge about open source software development.

The usual timeline of the contest is, it opens for students on end of the November and runs until mid of January. There are 25 open source organizations participating for Google Code-In this time.

Your role ?

As a GCI mentor , past GCI student or an open source contributor you have a responsibility towards the community. That is to expand the community awareness and transfer your knowledge to next generation. You gather experience while working on the open source projects and GCI is the best place to give your knowledge to youngsters while working with them. You should be devoted to guide students and give them an introduction to open source software development.

How students can be a part of the contest ?

Any pre-university student in age group 13-17 can register for the contest. The following four steps needs to be followed by the student to be eligible to compete in the contest.

  1. Sign up at g.co/gci after reading the Contest Rules.
  2. Ask their parent or legal guardian to sign the Parental Consent form.
  3. Find a task that interests them.
  4. Claim the task and start working while getting guidance from the mentors.

In return to their hard work and open source contribution, students can win digital certificates, t-shirts, hoodies based on their performance as well as a trip to Google HeadQuarters for Grand Prize Winner.

How to organize a local meetup ?

Since the Google Code-In contest is for pre-university students, I highly recommend that you organize a meetup for schools in the community. You can easily contact the club or society of the school which is related to Information and Communication Technology and convey your idea of the meetup so that the responsible person can get the management approval from their side to facilitate your meetup inside the school.

If you are not confident enough to conduct a session on your own maybe because this is a new experience to you, Don’t worry ! You can always call some other past GCI students, GCI mentors or open source contributors to collaborate with you in conducting a successful session. As open source world teaches us, it’s always collaboration that brings success to any project.

Taking the start to the meetup, you need to give an introduction to the Google Code-In. You may find different questions from the audience about “What is GCI?”. It is better if you can emphasize the importance of contributing to the open source projects since the students have no experience in that field. I suggest you to give students an insight on the evolvement of Google Code-In throughout the past years, so they get to know the real world statistics.

During the meetup, you need to focus on the 05 types of tasks that are available for students to claim, giving insights to what are the small small things that they really need to use in each task type.

  1. Coding
    • Give insights into GitHub and how to make a GitHub account, how to clone a project repository to their local machines and how to make a pull request.
  2. Documents and Training
    • Give insights into standard ways of doing documentation and basics to follow when conducting a user training.
  3. Outreach and Research
    • Give insights into how to make a blog account and write a blog as well as how to do some research on the project areas.
  4. Quality Assurance
    • Give insights into the measures that we take to assure the quality of the project and the steps that we take in order to make sure the project is adhered to the relevant quality measures.
  5. User Interface
    • Give insights into basic wireframing software like Balsamic as well as guidelines to a successful user experience.

It is really appreciated if you can share your experiences in open source contributions with them like what did you do, what you will be doing next and what obstacles that you had to face while contributing and how did you overcome those challenges. This will be an eye opener for them to think beyond the comfort zone. This section will be really helpful for the students to grab really what open source contributing is.

It is a best practice to conduct the session in an interactive way getting things done out of the box so that the students won’t get bored and they feel more energetic and comfortable since they feel that their opinion is also valued when we give time for their voice as well. Always motivate them to ask questions in the moments that they need more clarifications about what you are saying. In return if you have swags from Google, give them too since they will love it.

Always try to localize the session according to the audience that you are talking to. Use the language the majority of the audience is feasible with in order to make the meetup content more understandable to the community. You can use some slides so that you won’t miss the sections that you are going to talk about and the presentation flow will be really smooth to the initiative. Try to take an offline slide set with you in a USB drive, if you are making your presentation on Google Slides. Same for any videos that you are going to show up too.

Don’t forget to bring necessary cables/ converters(projector converters) with you and always remember to have a good internet connection with you if you are using internet for demos or other things  to eliminate connectivity issues which interrupt the meetup at some points and it is not a good impression to the students.

So far I wrote about how to organize a successful meetup in your local community on Google Code-In and hope this information will be very useful for you which I gathered through my own experiences when conducting the local meetups. I’m waiting to see some new meetups coming soon from all of you guys. Good Luck !

 

References

Continue ReadingHow to organise a successful Google Code-In meetup
Read more about the article Setting up SUSI Desktop Locally for Development and Using Webview Tag and Adding Event Listeners
SUSI Desktop

Setting up SUSI Desktop Locally for Development and Using Webview Tag and Adding Event Listeners

SUSI Desktop is a cross platform desktop application based on electron which presently uses chat.susi.ai as a submodule and allows the users to interact with susi right from their desktop.

Any electron app essentially comprises of the following components

    • Main Process (Managing windows and other interactions with the operating system)
    • Renderer Process (Manage the view inside the BrowserWindow)

Steps to setup development environment

      • Clone the repo locally.
$ git clone https://github.com/fossasia/susi_desktop.git
$ cd susi_desktop
      • Install the dependencies listed in package.json file.
$ npm install
      • Start the app using the start script.
$ npm start

Structure of the project

The project was restructured to ensure that the working environment of the Main and Renderer processes are separate which makes the codebase easier to read and debug, this is how the current project is structured.

The root directory of the project contains another directory ‘app’ which contains our electron application. Then we have a package.json which contains the information about the project and the modules required for building the project and then there are other github helper files.

Inside the app directory-

  • Main – Files for managing the main process of the app
  • Renderer – Files for managing the renderer process of the app
  • Resources – Icons for the app and the tray/media files

    • Webview Tag

    Display external web content in an isolated frame and process, this is used to load chat.susi.ai in a BrowserWindow as

    <webview src="https://chat.susi.ai/"></webview>

    Adding event listeners to the app

    Various electron APIs were used to give a native feel to the application.

  • Send focus to the window WebContents on focussing the app window.

    • win.on('focus', () => {
	win.webContents.send('focus');
});
  • Display the window only once the DOM has completely loaded.

    • const page = mainWindow.webContents;
...
page.on('dom-ready', () => {
	mainWindow.show();
});
  • Display the window on ‘ready-to-show’ event

    • win.once('ready-to-show', () => {
	win.show();
});

    Resources

    1. A quick article to understand electron’s main and renderer process by Cameron Nokes at Medium link
    2. Official documentation about the webview tag at https://electron.atom.io/docs/api/webview-tag/
    3. Read more about electron processes at https://electronjs.org/docs/glossary#process
    4. SUSI Desktop repository at https://github.com/fossasia/susi_desktop.

    Continue ReadingSetting up SUSI Desktop Locally for Development and Using Webview Tag and Adding Event Listeners
    Read more about the article Make Flask Fast and Reliable – Simple Steps

    Make Flask Fast and Reliable – Simple Steps

    Flask is a microframework for Python, which is mostly used in web-backend development.There are projects in FOSSASIA that are using flask for development purposes such as Open Event Server, Query Server, Badgeyay. Optimization is indeed one of the most important steps for a successful software product. So, in this post some few off- the-hook tricks will be shown which will make your flask-app more fast and reliable.

    Flask-Compress

    1. Flask-Compress is a python package which basically provides de-facto lossless compression  to your Flask application.
    2. Enough with the theory, now let’s understand the coding part:
      1. First install the module

    2. Then for a basic setup

    3.That’s it! All it takes is just few lines of code to make your flask app optimized .To know more about the module check out flask-compress module.

    Requirements Directory

    1. A common practice amongst different FOSSASIA  projects which involves dividing requirements.txt files for development,testing as well as production.
    2. Basically when projects either use TRAVIS CI for testing or are deployed to Cloud Services like Heroku, there are some modules which are not really required at some places.  For example: gunicorn is only required for deployment purposes and not for development.
    3. So how about we have a separate directory wherein different .txt files are created for different purposes.
    4. Below is the image of file directory structure followed for requirements in badgeyay project.

    1. As you can see different .txt files are created for different purposes
      1. dev.txt – for development
      2. prod.txt – for production(i.e. deployment)
      3. test.txt – for testing.

    Resources

    Continue ReadingMake Flask Fast and Reliable – Simple Steps
    Read more about the article Join Codeheat Coding Contest 2017/18

    Join Codeheat Coding Contest 2017/18

    Codeheat is a coding contest for developers interested in contributing to Open Source software and hardware projects at FOSSASIA.  Join development of real world software applications, build up your developer profile, learn new new coding skills, collaborate with the community and make new friends from around the world! Sign up for #CodeHeat here now and follow Codeheat on Twitter.

    The contest runs until 1st February 2018. All FOSSASIA projects take part in Codeheat including:

    Grand prize winners will be invited to present their work at the FOSSASIA OpenTechSummit in Singapore from March 23rd -25th 2018 and will get 600 SGD in travel funding to attend, plus a free speaker ticket and beautiful Swag.

    Our jury will choose three winners from the top 10 contributors according to code quality and relevance of commits for the project. The jury also takes other contributions like submitted weekly scrum reports and monthly technical blog posts into account, but of course awesome code is the most important item on the list.

    Other participants will have the chance to win Tshirts, Swag and vouchers to attend Open Tech events in the region and will get certificates of participation.

    codeheat-logo

    Team mentors and jury members from 10 different countries support participants of the contest.

    Participants should take the time to read through the contest FAQ and familiarize themselves with the introductory information and Readme.md of each project before starting to work on an issue.

    Developers interested in the contest can also contact mentors through project channels on the FOSSASIA gitter.

    Additional Links

    Website: codeheat.org

    Codeheat Twitter: twitter.com/codeheat_

    Codeheat Facebook: facebook.com/codeheat.org

    Participating Projects: All FOSSASIA Repositories on GitHub at github.com/fossasia

    Continue ReadingJoin Codeheat Coding Contest 2017/18

    FOSSASIA at Google Code-In 2016 Grand Prize Trip

    This year FOSSASIA came up with a whopping number of GCI participants, making it to the top. FOSSASIA is a mentor organization at the Google Code-In contest, which introduces pre-university students towards open source development.

    Every year Google conducts the grand prize trip to all the GCI winners and I represented FOSSASIA as a mentor.

    FOSSASIA GCI winners and Mentor at Google Mountain View Campus.

    Day 1: Meet and Greet with the Diverse Communities

    We all headed towards the San Francisco Google office and had a great time interacting with members from diverse open source organizations from different parts of the world. I had some interactive conversations with the kids, on how they scheduled their sleep hours in order to complete the task and got feedback from the mentors from different time zones! I was also overwhelmed while listening to their interests apart from open source contributions.

    “I am a science enthusiast, mainly interested in Computer Science and its wide range of applications. I also enjoy playing the piano, reading, moving, and having engaging conversations with my friends. As a participant in the GCI contest, I got the chance to learn by doing, I got an insight of how it is like to work on a real open-source project, met some great people, helped others (and received help myself). Shortly, it was amazing, and I’m proud to have been a part of it. ” Shared by one of our Winner Oana Rosca.

    There were people from almost 14 different countries, in fact, FOSSASIA, as a team, was the most diverse group 🙂

    Day 2: Award Ceremony

    We had two winners from FOSSASIA, Arkhan Kaiser from Indonesia and Oana Rosca from Romania. There were 8 organizations with 16 winners. The award ceremony was celebrated on day 2 and each winner was felicitated by Chris DiBona, the director of the Google open source team.

    Talks by Googlers

    We had amazing speakers from Google who spoke about their work, experiences, and journey to Google. Our first speaker was Jeremy Allison, a notable contributor to “Samba” which is a free software re-implementation of the SMB/CIFS networking protocol. He spoke on “How the Internet works” and gave a deeper view of the internet magic.

    We had various speakers from different domains such as Grant Grundler from the Chrome team, Lyman Missimer from Google Expeditions, Katie Dektar from the Making and Science team, Sean Lip from Oppia(Googler and Oppia org admin), Timothy Papandreou from Waymo and Andrew Selle from TensorFlow.

    Day 3: Fun Activities

    We had various fun activities organized by the Google team. I had a great time cruising towards the Alcatraz island.  Later we had a walk on the Golden Gate bridge. Here comes the fun part of the tour “the cruise dinner” which was the best part of the day.

    Day 4: End of the trip

    Oana, Arkhan and I gave a nice presentation about our work during GCI. We spoke about all the amazing projects under FOSSASIA. One cool thing we did is that we “Doodled” our presentation 🙂 Here are few images from the actual presentation.

    The day ended well with loads of good memories and information. Thanks to the open source technologies and their availability along with a beautiful friendly community, these memories and connections will now remain for a lifetime.

    Continue ReadingFOSSASIA at Google Code-In 2016 Grand Prize Trip
    Read more about the article Open Source Developer Guide and Best Practices at FOSSASIA

    Open Source Developer Guide and Best Practices at FOSSASIA

    I would request you to please guide me as to how can I collaborate with you and also how can I contribute effectively to the organization.

    At times I might get up to 20 private mails per day about “How to contribute to Open Source”. Usually I will direct developers to our mailing list or chat channels if they are asking about a specific project. But, how do contributions work at FOSSASIA? How can new developers join projects effectively? We have tried many different ways and spent a lot of time communicating with newcomers, many of them new to Git and Open Source development.

    Over the years we have gotten better at helping new developers, designers and other contributors to join up. We have more than 1300 registered developers in our GitHub organization today. Not all of them can contribute every day, but we do have thousands of commits every year.

    So, how are we able to scale up? I believe one reason are our Best Practices. We didn’t have a document “FOSSASIA Best Practices” yet, but in our daily work we have established excellent (mostly unwritten) best practices, that I would like to share in a concise form here now as a reference for new developers.

    Happy to get your feedback and comments.

    Development Best Practices at FOSSASIA

    Culture and Communication

    • Please adapt your language to non-native English speakers and be super friendly. Remember we are an international community with contributors mainly from Asia and Europe. We are not used to swearing and will mostly understand words literally. At all times ensure your tone stays appropriate and friendly in the FOSSASIA community.
    • Stay modest. Sometimes newcomers already have an amazing knowledge in some areas. Still remember, it is no reason to be arrogant. Even the best developer does not know everything.
    • 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 appreciation for the good work of your co-developers.
    • If you are involved in a topic you don’t understand yet, try to learn yourself as much as possible from public channels (wikipedia, stackoverflow) but also do not hesitate to ask questions to other developers.

    Communication Channels

    Every project at FOSSASIA has its own channels. Many projects use Gitter, some Slack or IRC. Usually you will find information of the main communication channels of a project in the Readme.md.

    While we are a community of Open Source and Free Software developers we still reserve our right to use whatever tools we deem necessary to help us to achieve our goal of developing the best possible Open Technologies – software and hardware. It is one step at a time 🙂

    Private and Public Chat or Issue Tracker

    Chat is a great way to connect with other contributors, but not all contributors are there all the time (consider time difference and personal schedules) and they are not always available to chat. Chat tends to be unstructured and with lots of people in a room there are often a number of threads. Therefore chat is great for help on setup issues and things where you got stuck.

    Do not use chat for feature requests and detailed discussions on issues. These things are best for the issue tracker, where people from different timezones can join and where a focused conversation on one specific topic can happen.

    Some people try to overcome the unstructured chats by switching to private communication. This shuts out other contributors who might have similar issues. A result I often observed is also, that contributors will bring up arguments in discussions like “I have discussed this already with xyz privately and he agrees”. Other contributors have not seen this discussion if it has not been 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.
    • 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 some weird/rare one.

    Join Development

    • Before you join development, please set up the project on your local machine, run it and go through the application completely. 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. Only thing that will happen is, you’ll be more familiar with what is where and might even get some cool ideas 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 free to drop in a comment so that the issue can be assigned to you if the previous assignee has dropped it entirely.

    Commits/Pull Requests

    • All pull requests need to be associated to an issue.
    • All PRs need to be assigned to the person working on it.
    • 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 write rights to the repository, do not create new branches, 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 info in the issue itself).
    • Write clear meaningful git commit messages (Do read http://chris.beams.io/posts/git-commit/).
    • 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 at https://github.com/blog/1506-closing-issues-via-pull-requests).
    • When you make very minor changes to a pull request of yours (like for example fixing a failing travis build or some small style corrections or minor changes requested by reviewers) make sure you squash your commits afterwards so that you don’t have an absurd number of commits for a very small fix (Learn how to squash at https://davidwalsh.name/squash-commits-git).
    • 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 it much easier for the reviewers and helps to speed up the process. You’ll also get reviews quicker.
    • Add a link to your deployment of the project, where reviewers can check out what you have changed (especially for smaller changes this is very helpful as the reviewer might not even need to set up the system itself and test it. Again this speeds up the review process a lot).
    • 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 and solve merge conflicts to speed up the process.).
    • Merging Pull Requests should only happen if at least two contributors reviewed the PR 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 for them. For example, if an issue is about changing a font, do not also change the color even if this seems like 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. 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 FOSSASIA Projects have:

    • a development branch (which is the working branch. Please commit to this branch.) and
    • a master branch (which is the stable branch).

    Some projects also keep additional branches e.g.:

    • gh-pages for documentation purposes (often autogenerated from md-files in docs folder)
    • apk branches for Android apps (often autogenerated with travis).

    Getting Started

    • Newcomers are sometimes afraid 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 with errors.
    • In simple issues keep it simple and “simply” 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 to review other commits.

    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 not any design specifications in the project yet, why not start them and add a section into 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.

     

    Thank you for helping to define many of the practices while working on the Open Event project to the developer team and for additional input and links to Niranjan Rajendran.

    Links to Other Resources

    Continue ReadingOpen Source Developer Guide and Best Practices at FOSSASIA
    Read more about the article How to join the FOSSASIA Community

    How to join the FOSSASIA Community

    We often get the question, how can I join the community. There is no official membership form to fill out in order to participate in the Open Tech Community. You simply start to contribute to our projects on GitHub and you are already a member. So, let’s work together to develop to develop social software for everyone!

    The FOSSASIA team welcomes contributors and supporters to Free and Open Source Software. Become a developer, a documentation writer, packaging maintainer, tester, user supporter, blogger or organize events and meetups about our projects.

    Women in IT discussion in the community

    Here are some ideas how we can collaborate

    Download our Open Source applications, install them and use them

    The first step of joining a project is always to download the software and try it out. The best motivation to support a project is, if the project is useful for yourself. Check out our many projects on github.com/fossasia and our project social media Open Source search engine on github.com/loklak.

    Show your support and ★star FOSSASIA projects

    Help to motivate existing contributors and show your support of FOSSASIA projects on GitHub. Star projects and fork them. Doing something that people like and that helps people is a great motivation for many.

    Learn about best practices

    We have formulated best practices for contributing to Open Source to help new contributors to get started. Please read them carefully. Understanding our best practices will help you to collaborate with the community and ensure your code gets merged more quickly.

    Subscribe to news

    Subscribe to the FOSSASIA Newsletter to stay up to date on new software releases, events and coding programs here on the main page.

    Read the blogs and support users on the mailing list

    Learn from Open Tech articles on our blog that are written by developers, contributors, volunteers, and staff of companies supporting the FOSSASIA network. Sign up for the FOSSASIA Mailing List and keep reading our blog at blog.fossasia.org.

    Follow us on Social Media

    Show us you interest in FOSSASIA’s Open Technology and keep up to date on new developments by following us on Twitter and retweeting important updates: twitter.com/fossasia

    And, become a member on social networks like Google+ and Facebook and connect with other contributors:
    * Facebook www.facebook.com/fossasia/
    * Google+ plus.google.com/108920596016838318216

    Join and support the FOSSASIA network at community events

    Set up a booth or a table about FOSSASIA at Open Source community events! There are many events of the open source community all over the world. The core team of FOSSASIA is simply not able to attend all events. You can support the cause by making the project visible. Register as a member of the FOSSASIA community at events, set up an info point and showcase Free and Open Source projects. Check out for example FOSSASIA event calendar calendar.fossasia.org or our meetup group in Singapore: meetup.com/FOSSASIA-Singapore-Open-Technology-Meetup

    Translate our projects and their documentation

    Do you speak more than one language? Most Open Tech projects are 100% volunteer translated, which means you can be part of a translation team translating software and documentation thousands of people will use. Start now and check out our GitHub repository.

    Mini Debconf Participants in Saigon

    Continue ReadingHow to join the FOSSASIA Community