Other way to do community

ngLabs is a small community that I founded in April of 2017. If we have in count that we closed in July and August, the community has only three months of activity. However, during these three months, we’ve done two workshop with full house and an event per week with around 30 regular attenders. In my opinion, as a rookie in the community it is a success. This is the story of our experience.

What is exactly ngLabs?

NgLabs is a group of people who meet to do Open Software projects. The projects in ngLabs should have, as main mission, to learn about Angular and the technologies which are around the framework.

Each project is classified in one of the next categories:

• Rookie: A rookie project is a project which only needs Angular knowledge. Usually means to code a frontend which use a public api. That’s all.
• Expert: An expert project covers Angular and some of its satellite technologies (like Ionic, NativeScript, Apolo, etc…). This kind of projects is for people who feel comfortable with Angular and they want to go further. However, the technologies of an expert project are not experimental. They should have a strong community behind with a good documentation and tutorials that the team members can use to solve their doubts
• Innovation: A project of Innovation is a project where the people are trying to create something new. It can also be a project to help to develop a alpha version of other open software project.

The process to create a new project in ngLabs is the next:

1. The person who wants to start a new project (from now on I’ll call it PO) tells the idea to a ngSherpa (in a moment I’m going to explain what a ngSherpa is)
2. The ngSherpa evaluates the project and gives it a category (Rookie, Expert or Innovation)
3. The PO opens a new Kanban project in taiga and prepares some slides to explain the project
4. In the next meeting, the PO has 30 minutes to explain the project and convinces the attendees to join with him
5. The ngSherpa open a new repository inside the ngLabs organization in Github and a new channel in our slack for the project.

After the presentation of the project each team goes to a table and starts to work in their project. So basically, the majority of time, what the people do in ngLabs, is to work in their projects.

One of the main worries of the ngLabs members is that anyone gets stuck in a problem. We want to keep the momentum of the project and, for this reason, to have progress in the developments is really important. In the case that someone cannot resolve a problem there are three levels of help that it can use:

1. The team partners
2. The ngLabs partners
3. The ngSherpas

If the team partners don’t know the solution, the person with problem can ask to the rest of people who are in the room working in others project. It can also launch a question in our slack. If there isn’t a good answer, the ngSherpas will give one. The fact is that no one is alone in ngLabs. The members of the community will always find support in their partners. For this reason there is no problem is someone wants to start a project alone (it is not advisable but we don’t oppose it).

We are agile

The projects follow the kanban methodology. The PO of each project manages a Kanban board in taiga with the list of task that the team should accomplish to finish the app. We also have sprint that usually last about two months. Think that we do one meeting per week of 4 hours. Each month has 4 weeks which means that each sprint has around 32 hours. However, not all hours are to code. There are 3 days in each sprint that we spent in:

• The planning for the sprint
• The demo and the retro
• A very practical workshop

So, at the end, to work in the project, we only have 20 hours per sprint (in addition of what the team members want to dedicate in their free time in home)

About the planning, at the beginning of each sprint the PO has a meeting with the others members of the team to check the state of the kanban board. The objective is to decide if they need to add a new tasks, to remove tasks or to change the priorities. They also decide who will be responsible of what task.

The workshop is also strongly related to the projects. The ngSherpas ask the teams what is the most difficult issue for them and prepare a workshop on this topic. For example: Our first workshop was about automatic tests and the second was an introduction of Angular for beginners. The next one will try to explain what the observables are and how to use them in the projects. If I am honest with you, I am very proud of our workshops. They are open to all and we always have a full house in them all. I think the key to their success lies in that they focus on solving the real problems we face in our projects … and, usually, these problems are the same that other developers have to face in their day to day.

The last day in the sprint is for the demo and the retro. In the demo, each team shows the rest of us what they have achieved in these 20 hours of work. In the retro, the teams analyze what they can do better for the next sprint and what ngLabs can do to help them. I have to say, without a doubt, that the best of ngLabs are retros. In the end, ngLabs does not belong to me, even though I am its founder. It belongs to the people who do the projects because it is what these people want it to be. For example: In the beginning our sprint lasted a month but, in our last retro, the members told me that they did not have enough time to make real progress, so we decided to extend the time to two months. We used to get together on Saturday, but some people suggested that we should try to hold meetings every Friday and Saturday to see if it is easier for the rest of the members to assist at the meetings. The ngSherpas was also an idea coming from a retro. Therefore, ngLabs is not stable; is a community that undergoes strong changes every two months to try to find the best way to help its own members … and it is incredible.

The ngSherpas:

As I said before, the idea of ngSherpas came out in the last retro. The people who went that day told me that they need a clear reference to resolve doubts, someone who has to have experience developing in Angular. The exact words were “someone who guides us from the bottom to the top.” That’s where the word “sherpa” appears because a sherpa is the person that guides you in the Himalayas from the bottom of the mountain to near the top. The idea was great, the concept fantastic, everything fit in my mind. So in the end, an ngSherpa is a mentor, a person who has experience developing in Angular and comes to meetings to help projects when they get stuck on some issues. It is important to note that a Sherpa does not want to create a strong dependency with any project. They want project people to become independent of it, so a ngSherpa will never implement the solution, it will show ways to solve it. The final decision must be chosen by the project.

Other thing that the ngSherpas do, as an expert, is to classify the new projects in one of the categories that I mention before. They can also prepare the workshop or propose other experts to do it.

A ngSherpa is chosen by its own team partners. When a project is finished, the team choose the best developer of the project, the one who inspires them the most confidence. The ngSherpa has also a category depending of the type of the project that it finished. For example: a ngSherpa for rookies will be one who has become sherpa after to end a rookie project. A project should ask for help to a ngSherpa of the same category.

NgSherpas are members of ngLabs as well as others. Consequently they can attend the workshops as everyone, to participate in the projects or to propose a new one. In fact, if a ngSherpa wants to change category (to become a sherpa of innovation or expert), he has to finish another project in this category and be chosen by his partners.

The software:

The main mission of each project in ngLabs is the training. What I’m trying to say is that usually, our apps, don’t try to supply a necessity to create a business. Our objective is to train our self through developing software together. It is good because:

1. We don’t have any pressure of time or money
2. We are free to try any crazy idea because we don’t have nothing to lose

However, it could happen that an app developed by a team fits really well with an opportunity of business. In that case, ngLabs doesn’t want that anyone take advantage of the member’s effort for its own business and ngLabs doesn’t want any reward from the work of their members. For this reason all the projects are under MIT license. If anyone wants to create an app based in one of our project, he or she can do it… as well as everyone in the world. In consequence, in ngLabs, everyone works for nobody except theirself (I’ll explain this in a moment…)

The end of a project:

I have already explained that, at the end of a project, a team member is chosen to be a new ngSherpa, but it is just one of the things that happen. When a project is completed all team members must do a troll conference. The troll conference is the event in which a team explains their project (what it does, how it does, etc …). In this type of events there is always an expert angular developer who is the troll. The troll can not speak or do anything while the team is exposing their project. It have to wait until the round of questions is over. Then the troll is released.

The goal of troll is to find problems or errors of any kind (architectural errors, maintenance problems, performance problems, etc …) that the team has not seen. It should also tell them how to solve them or how to improve the software. Of course, this event is not to humiliate anyone. What we want is for developers to learn from their own mistakes. It is the opposite of what we usually do in a conference. Usually, the expert teaches us the right way to do things to normal people. In this case, normal people are telling the expert how they do things. This new point of view of non-expert developers could be good, could be different or could be wrong and, when faced with expert vision, everyone learns something new; the team of developers, the expert and the audience of the event.

After troll event, it is time for the promotion. NgLabs encourages all the people who has ended a project that they should do some kind of promotion of the results and conclusion of their work. This promotion can be a talk in one of the different meetups in the city, articles in a blog, some video on youtube, etc… anything to make known their work. During this promotion, ngLabs don’t want to get any credit. The team doesn’t have to mention the community if they don’t want. It’s their work and they deserve all good things that come from it.

It is not so Angular:

Usually some people ask me why I’ve done a lab (ngLabs is a software lab) just for Angular. Well, the reality is that ngLabs is not just angular. As I said before, in ngLabs, we make open software. It is our way of learning from others. The software has only one reason to be: to be deployed. If you have implemented an Angular application, you will know that the framework is not enough. With Angular you can only build the front. In the easiest case, I’m talking about a Rookie project, you’ll need a web server, so, some knowledge about Apache, nginx, express … will be needed. Each Angular application also has to have a user interface, so to know about UX and UI design is important as well.

If we think of an expert project, the technology stack grows a lot. All applications will need a data source so the team will need to obtain knowledge of, at least, one database (Postgresql, MySql, MongoDB, Firebase, CouchDB). At the same time, a data source means an API to consume it (GraphQL, RAML, Swagger, etc …).

If we are talking about hybrid ( Ionic ) or native ( NativeScript ) apps some sort of knowledge about Android and IOS systems is needed. With isomorphics we have to know express or Koa, PWA needs service workers and, depending of how we want to deploy, it is possible we need dockers and server less system knowledge.

So, yes, we have Angular as a common point but at the end, the number of different technologies that we use is quite big.

Conclusion:

I recommend you to read the story of “the stone soup”. This story tell us that if we want something from others, instead of asking for help, we should share what we have so everyone get something in exchange. This is the philosophy of ngLabs.

In our community people learn from each other by sharing their knowledge. The result of your work is useful as a portfolio that can be added as proof of your skills. At the same time, they have training in some of the most demanded technologies, as well as one of the most successful methodologies to carry out the project as kanban and agile values.

The troll conference compares their form of coding with the vision of expert developers and the promotions of their result make them gain a presence in the software community which usually gets the attention of companies. Certainly, being part of ngLabs is a win to win for everyone.

I don’t want to finish this article without to thanks the meetups of AngularMadrid and MadridJS which help me in the promotions of the events that we have done until now. I also want to thank Liferay spain to borrow us their office to do our meetings. Thank you everyone for your support and I expect this year will be better for ngLabs and the software communities of Madrid.