This is a topic that never was standardized, We covered this for some positions in the past.
But I think that we should define this properly and add it to the guide and the offers.

A preliminary amount agreed with Eiso, is up to 2000e, if you are moving from another country.

source{d} office in Madrid is awesome open space, but on the pick of productivity it also may become a little bit noisy, and the list of available hardware does not include any silent keyboard option ⌨️

I would like to know if anybody else, for the sake of sanity of your colleagues, would be interested to fix it, if an option is provided for those honorable souls who feel empathy for their co-workers: by choosing the same keyboard, but with Cherry MX Red Silent Switches.

🙏 🙏 🙏

It would be really great if we could allow for a option of exactly the same keyboard Fnatic Gear Rush that we already have but with Cherry MX Silent switches - Amazon.es, official web-site

It's exactly the same, but would allow your may-be-misophonic colleagues to stay calm and more relaxed, while working from our spacious office in the center of Madrid.

It is possible to take a vacation which intersects with holidays or weekends. In Russia, they count it as a part of your vacation and not adjust the vacation factual length (but you've got 28 days). I am not sure how it is in Spain: are they included or discarded?

Now we do Open Source Days.

The main section to change here is the "How To" section.

Was checking with KinHR support and it seems we currently have a maximum 23 days carryover policy set there, which conflicts with:

Finally, if you don't use all your days in one year, any unused days will carry over to the next.

From : https://github.com/src-d/guide/blob/master/talent/flexible_holidays_working_schedule_remote_work.md

Their customer support answer on how to fix it:

If you wanted to have an unlimited amount of carryover, you can set the maximum to a very high number (say 100 days). Then, in this scenario, you would be able to carry over 35 days (35 + 23).

From: https://github.com/src-d/guide/blob/fe18e8d07939d8751fd237ab56fbe096cfe0e7fc/general/expenses_travel.md#what-expenses-are-covered-when-travelling

I asked @estherrgarcia about this because of this week because I'll be staying at my beach house during Jon The Beach 2018 but she said it has never been done before so she doesn't know how to proceed.

cc @jorgeschnura

It's better to have it here to avoid misunderstanding. Thanks!

For an outside person it's not very clear what Data Intelligence, Machine Learning and Applications teams are doing and how they communicate with each other. (for other teams it's more or less clear because of the name, but not how they are connected)
In my opinion it's worth to explain the process of development here. Some graph like this:

Data Retrieval => Language Analysis => Machine Learning 
                                                        =>  Applications => Infrastructure
                          Product

And some description like:

Data Retrieval - retrieve and store source code from one project to all of the world's public code. Build such projects as go-git, rovers, borges, siva
Language Analysis - language detection on a large scale and build querying, features extraction, collects statistics for any programming language that enables code analysis for all open source code and enterprise. Build such projects as envy, babelfish
...
Applications - applies whole stack and expertise to solve real word problems as code duplication, smart diffs, search for repositories, projects evolving reports
Infrastructure - runs kubernetes cluster on bare metal and AWS to allow process millions of code lines every minute

P.S. Anything above can be incorrect and just my fantasy, because I don't really know how everything works yet.

In some of our projects we don’t have release notes properly executed with a detailed changelog (preferably with links to issues), and sometimes no release notes at all, which is bad for internal and external users.

We should have general guidelines on the guide to standardize the content and process. E.g.:

• How frequently/what prompts a release?
• What should be provided in terms of files?
• What content should each release have and in what format?

According to research, one of the down-sides of working remotely is that is becomes harder to establish a personal relationship with other team members.

For this reason, I would create either a Github repo or a Slack channel (or both), where everyone has to post an introduction of themselves. This introduction (precise content to be defined) should have personal questions, as well as a link to those social media accounts (Instagram, Twitter, Medium, FB, etc.) the new sourcerer is comfortable with sharing, so that we can establish more personal relationships outside of work activities.

Ideally it should be a Github Issue per member, where we can use the comments to ask questions to the new member. Once the issue is posted it should be published on a "new_sourcerers" Slack channel so that people get notified.

The current code review policy is that PR made to public repos must be reviewed by Máximo and another person: https://github.com/src-d/guide/blame/master/engineering/git-flow.md#L23

But I think that is not going to scale well now that we are publishing so many repos.

I don't know what was the original intention behind this rule, so I cannot propose alternatives that preserve it.

There are people that assert that:

A great offboarding experience can also woo stellar “boomerang employees” to come back in the future or recommend the company to their qualified friends and family.

Do you think it could be a good idea to define the process or try to explain it?

Random example with rationale and checklist

It would be really great to have a recognized communication medium at source{d}, where everyone could engage in meaningful discuss on meta-topics. With some arguments, threads, links to each message and some time to think and an opportunity for everyone, even the least loudest persons, to express their opinions on important subjects.

Fiding such communication medium is VERY hard thing, both technically and culturally.. and Slack/IM does not address it (and has it's own issues as main communication tool).

Coming from open source community background, this means finding an equivalent of Mailing List archive.

ML archive itself is sub-optimal in many ways (using only emails as transport), but it is:

• async
• threaded
• searchable
• has calendar navigation
• each thread has permanent URL, that’s easy to get back to, share, link in sub-sequent discussion, etc

I know that email is un-popular choice at source{d}, but I really wish we find something that works for us… so why do not we try this repository's issue?

This is especially critical, as source{d} faces a challenge to become a remote-first company - otherwise, you know, "all these moments will be lost in time, like tears in the rain".

There is already some good start like #72 and #81 - let's see how that goes.

What do you guys think? Is that actually a pain-point for anybody else? If so, do you think suggested solution might work? Looking forward your opinions!

If the quests have a logical order to them, better to make this explicit.

As a new hire myself, here are my thoughts on what can be helpful for the first few days:

1. Have a standard template for the onboarding issue checklist. For example, there is nothing terribly wrong with my issue (https://github.com/src-d/office/issues/22), but if it was a template in a repo I would open issues to

   • List all the mailing lists that I will be added to, and the purpose for each one
   • Add the welcome talks

2. Have a template for a welcome email. I think a short email can be a nice and simple point of entry to refer at a later date.
   Something along the lines of:

Welcome to source{d}. Here are few first steps to get you going:

• Read the guide.
• This is your personal onboarding issue (link). Fell free to reach the person responsible for each item.
• In the Applications/Infrastructure/... team we use these tools: (list of tools and what they do. e.g. github project board, Geekbot, etc)
• We have a lot of repositories, but for now you should focus on getting familiar with the contents of (list of relevant repos for your team/role).
• Consider turning on github notifications at least for (list of repos)

Design document template is not linked here: https://github.com/src-d/guide/blob/master/engineering/workflow.md#design-document-1st-iteration

First of all, thank you for this repo. It's really helpful.
The only matter that is still unclear for me is about the product.
According to Roadmap and manifesto it looks like there is more than one.
The first one is a platform to connect developers, projects and companies through code. Is it another approach to "fix developer recruitment"?
The second one is real-time assisted programming. Do you plan to develop some tools and make them another product?
Which of them is more important? On what do you want to focus?
Do you mind to open not only how you do things, but how you sell it to potential investor?

It should describe our process, how to apply, and how to refer candidates.

Proposal for improvement:
I think it will be really useful if we will have some integration with slack to make a notification about pending reviews.
Right now it's pretty easy to miss mail from GitHub.

Given that KINHR tracks holidays that are in the Madrid office, what is the policy for people working remotely and subject to different national holidays (and the alike)?

P.s.: for example, the workaround so far with Ricardo, is: he schedules on KINHR asking for holidays on the days of Portuguese national holidays, and whenever he works regularly in a day that's a national holiday in Madrid he gets a +1 day. It makes the math check out and give transparency to it.

It would be great to summarize our engineering conventions like which logging or testing libraries do we use, how do we handle errors...

For example, I came across with "Choose one log library for Go and implement on all the projects" but I could not find it easily; we also own many big projects using the discarded library, what could lead to misunderstandings.

Not all people know what things do we use when we develop, and I'd find quite useful if all these conventions would be described under guide/engineering

• Logging → Logrus (by https://github.com/src-d/backlog/issues/840#issuecomment-343930191)
• Testing testify or go-check
• Library to use in CLI commands → go-flags
• When to use src-d/go-errors
• CodeReview guidelines for Go → are we following the Go Code Review Comments guide?
  • Code conventions and styles for other langs like Scala, Python, C++ (as suggested by @juanjux)
• Vendoring and dependencies as sugested by @bzz
• CI, CD and building as discussed at code-annotation PR
• How we do continuous delivery for web apps
• Store linter configurations and rules for different languages in src-d/ci
• ...

Hi!

We need to decide about licenses we can (have to) use for public datasets and add it to guide.

Examples of licenses:
In PGA: https://github.com/src-d/datasets/blob/master/DCO
In other dataset related to data from Github: https://www.kaggle.com/davidshinn/github-issues

One of the main issues that happen with remote teams is that you lose the "serendipity" of conversations starting and ending up in something new and useful.

I'd like to open up this discussion with a proposal in order to avoid this issue:

I'd like to set up a screen in the kitchen with a webcam where a Zoom Room is constantly open and you can see the people who are working remotely. These people would decide if they are muted and/or deafened. The idea is that you can start a casual conversation with any of them or that they can join a kitchen conversation as if they were in the office.
It would also be possible for people who are remote and have joined that same Zoom Room to start a conversation with each other as if they would be sharing a physical room.

Potential issues: The kitchen will become less private as anyone in remote and logged into that room can undeafen theirself and start listening to any conversation happening.

Everyone working remotely would be encourage to join this Zoom Room if they want to in order to be better integrated with the rest of our team members.

This idea can be executed with or without the kitchen solution.

Should we merge trivial changes such as a fixed typo in README without sign-off?

See practical example: src-d/gitbase#292 (comment)

cc @eiso

On Quest 1: Setup your machine on Arch Linux of the By Developers Training we have:
Duration: 2 days and Deliverable: Fully set-up laptop

That seems good particularly during the onboarding experience. Some however mentioned that the idea is that the person in training would have to use the set up laptop with Arch for work afterwards instead of their OS of choice.

So a few questions for clarification:

1. Is the person in training supposed to do this on their main work laptop or can it be a spare one?
2. Does the person need to use it afterwards for work for any given amount of time?
3. If that's the case above, how to deal with jobs who required different setups/OSes?

Thanks!

I'm not sure about that, but AFAIK there is a chance that CWMs and Demos are being recorded, so if possible, I'd like to quickly clarify few questions:

• if that is true, should we announce that somehow to everyone?
• shall we declare some simple internal policy on how these materials are going to be used? To avoid any possible privacy concerns
• and more practical, how would one watch it?

Sorry if I have missed it, would really appreciate if somebody could clarify those points, as quick search (record|recording) over https://github.com/src-d/guide and https://github.com/src-d/minutes did not reveal much.

I would like to suggest/propose for us, as a company, to have an attitude towards helping people in Madrid in difficult conditions, as volunteers. As an example, doing some Community work to help homeless people. I do it in Lisbon as volunteer for Comunidade Vida e Paz.

I propose you rename this repository to src-d/about which reflects much more cleanly the intention of the documents placed here.

There are some legitimate cases for pseudonymous contributions, but that might legally complicate the whole DCO policy.

We are currently rejecting such contributions, but we might consider if we are able to legally accept them.

See: src-d/go-git#819

The main readme contains a huge table of contents that is easily outdated when it appears new content.

What if each section would contain its own README.md instead of maintaining a general one?
That way, each section could have its own description, index and even more: its own owner ("maintainer"),

for example: .github/CODEOWNERS could be:

# default
* @jorgeschnura 

# sections
developer-community/* @campoy 
engineering/* @mcuadros 
general/* @jorgeschnura 
office/* @estherrgarcia 
talent/* @tsolakoua
product/* @marnovo

We currently copy the content of:

• CODE_OF_CONDUCT
• DCO
• the first five sections of the CONTRIBUTING

Would it be useful to link to that files in src-d repositories instead of copying its contents?

About the CONTRIBUTING.md, since each project is different to the others, there can be special requirements (like the development section). If/when it happens, the project CONTRIBUTING.md would contain the link to the company one, plus the local differences.

If we do so:

• the maintenance of those files will be easier,
• it will be ensured that all our repos follow the same rules,
• it will be easier for us to know (and validate) what differences do we require for certain projects.

Would love to see some of these adapted to source{d} and implemented (I can help):

Google is sharing its management tools with the world

Speaking at his alma mater in January, Sundar Pichai, Google’s low-profile CEO, revealed his key to effective management: “Let others succeed.”

Enacting Pichai’s advice is easier said than done. But Google is sharing some tools that might help. Its Re:Work blog is offering a series of instructive documents used by managers at Google. They cover everything from feedback and career development to setting agendas for one-on-ones, and codify the insights Google gleaned from spending years analyzing reviews and other observable data at the company to determine essential leadership traits.

Here’s an overview of what’s available. Each section header below has the link to the corresponding documentation from Google.

Manager feedback survey

Googlers evaluate their managers on a semi-annual basis with a 13-question survey. The first 11 measure whether employees agree or disagree with statements like “My manager shows consideration for me as a person.” The final two questions (“What would you recommend your manager keep doing?” and “What would you have your manager change?”) are open-ended.

At Google, these survey responses are reported confidentially, and managers receive a report of anonymized, aggregated feedback, plus verbatim answers to the two open-ended questions. “The feedback a manager gets through this survey is purely developmental,” Google says. “It isn’t directly considered in performance or compensation reviews, in the hope that Googlers will be honest and constructive with their feedback.”

Career conversations worksheet

Google’s management analysis reveals that above all, employees value knowing that their manager is invested in their personal success and career development. To help managers effectively discuss development with their direct reports, Google uses the GROW model—which organizes the conversation into four recommended sections:

• Goal: What do you want? Establish what the team member really wants to achieve with their career.
• Reality: What’s happening now? Establish the team member’s understanding of their current role and skills.
• Options: What could you do? Generate multiple options for closing the gap from goal to reality.
  Will: What will you do? Identify achievable steps to move from reality to goal.

“One Simple Thing” worksheet

To encourage personal well-being and work-life balance, Google uses the popular goal-setting practice “One Simple Thing.” The goal should be specific enough to measure its impact on one’s well-being. “Managers can encourage team members to explain how pursuing this one thing won’t negatively affect their work,” Google explains. “That goal then becomes part of a team member’s set of goals that managers should hold them accountable for, along with whatever work-related goals they already have.”

Some examples of “One Simple Thing” goals include “I will take a one hour break three times a week to work out,” and “I will not read emails on the weekends.”

1:1 Meeting agenda template

At Google, the highest-rated managers hold frequent one-on-one meetings with their direct reports. However, as most leaders know, individual check-ins can often feel rushed and disorganized. To squeeze the most out of each one-on-one (which Google managers are advised to hold every week or two) Googlers set up a shared meeting agenda ahead of time—which both the manager and the report should contribute to.

Some agenda items Google suggests include:

• Check-in and catch-up questions: “What can I help you with?” and “What have you been up to?”
• Roadblocks or issues
• Goal updates
• Administrative topics (e.g., upcoming vacations, expense reports)
• Next steps to confirm actions and agreements
• Career development and coaching

New manager training course materials

As Google explains, “These course materials were originally designed for Google managers to help them transition from individual contributor roles to manager roles.” As anyone who has done this can attest, conducting the transition gracefully requires a bit of perspective shifting, and more than a little awareness building.

The course materials include a facilitator guide (to help whoever is training the new managers), a new manager student workbook (including interactive exercises), and the presentation slides that Google trainers use internally.

If we could know about the get together requirements and limitations, we could propose events on our own.

To do so, I think we should know, at least:

• budget,
• the minimum amount of people needed,
• the days when it can occur,
• when can we leave the office and when should it finish,
• if is there any limitation/expectation on the time duration,
• if there is a distance limit (regardless the one limited by the budget, time limits and
  duration),
• if the +1 invitation should be always an option, or it depends on the activity,
• if the activity must include drinks and/or food,
• the process to be approved,

and any other I could miss

As requested in #99

The link for Arch Linux Setup is broken. It’s currently
https://github.com/src-d/guide/blob/master/talent/by-developers-training/linux.md

I believe the right one is:
https://github.com/src-d/guide/blob/master/talent/by-developers-training/arch-linux-setup.md

https://github.com/src-d/guide/blob/master/talent/open_source_days.md needs to be updated to the remote first workflow without sprints.

Since we're trying to improve the way our users/developers/visitors approach our projects, I think it could be a good idea to propose a project skeleton to be followed.

Benefits of having a common skeleton already pre-defined:

• it makes our projects more homogeneous, what lets everyone to know what to expect where,
• it would let us start a project with all our agreed requirements ready to be fulfilled,
• it could be also used in "starter apps" (like src-d/platform-starter)

Context:
I imported this idea from documentation at source{d} #84

In my opinion, the following could work:

project-skeleton/
├── .github
│   ├── CODE_OF_CONDUCT.md
│   ├── CODEOWNERS
│   ├── CONTRIBUTING.tpl.md
│   ├── ISSUE_TEMPLATE
│   └── PULL_REQUEST_TEMPLATE
├── DCO
├── LICENSE.apache
├── LICENSE.gpl
└── README.tmpl.md

And I'd put that directory under guide/engineering/

Quest 3 is not solvable in one hour unless we only want people to have a really basic understanding of who they are and what we do. Furthermore, this discourages discovering new things through links or investigating other project similar to what we do.

"As a source{d} team member I would like to read a cool book on working remote so I can be better at it"

My first suggestion is https://basecamp.com/books/remote

@mcuadros I definitely saw the rules you wrote to merge PRs somewhere. We need to put them here. E.g.

private projects - 2 people must approve
public projects - 3 people and Maximo
...

Besides, it would be awesome to list the owners of each project who can merge PRs backing Maximo. E.g. myself in src-d/blog, etc.

Besides, there is an exclusion with ML projects since only me and @EgorBu are able to understand what's going on.

I propose that we start using Semantic Linefeeds in this repository. See [1] to know why.

[1] http://rhodesmill.org/brandon/2012/one-sentence-per-line/

Considering the feedback given at src-d/blogpull/176#issuecomment-356458445, it seems to be needed to improve the continuous delivery for web sites guide.

It would be also great to link that doc in the guide/README, or —even better— in a new guide/engineering/README

Two really great resources for learning command line and git. Very well explained and ramp up in complexity well.

Might event be "core-quest" material, if not at least a must-be for the "DLC". Let me know your opinions on them.

• CLI: https://www.learnenough.com/command-line-tutorial
• Git: https://www.learnenough.com/git-tutorial

As mentioned by @eiso at src-d/office:

@estherrgarcia could we add a list of books that we [have] at source{d} to the guide.

As per discussion here src-d/conferences#63 it seems source{d} employees do not need to sign-off.

If that is the case, we would need to:

• update both our DCO checker for PRs (which, I guess, would require everyone either signing-off or committing with the corporate email)
• update the guide https://github.com/src-d/guide/blob/956c0d0d240abc8e5dd37df9fdb8bb8ce34768fe/engineering/licensing.md#developer-certificate-of-origin since it currently says:

All our projects should include a Developer Certificate of Origin (DCO) document to protect us against any individual contributor revoking our rights to distribute their contribution to any of our projects.

In practice, this means that every commit since the introduction of the DCO, should be signed off by the author, using git commit -s. Being irrelevant if the author is a source{d} employee or an individual contributor.

@eiso @mcuadros

I recently asked a question intended to be seen by employees only to a public channel by mistake.

I'm proposing to add some kind of prefix to all the public channels so this mistake won't happen again

Unfortunately slack doesn't support emoji on the channel names (😱) so maybe we could use a utf8 that kinda looks like a globe? I propose ۝

The gide:licensing only defines:

• GPL v3.0, applied to all projects whose nature is specific to core parts of our stack
• Apache License 2.0, to projects which are libraries or tools that intended to be consumed by third-parties as a source code dependencies

But there are editorial content like Landing or Blog that could not fit under these descriptions.

Should be one of them, or should they be relicensed under a common Copyright (c) ${YEAR} source{d} as done by landing or blog?

@mcuadros https://github.com/src-d/guide/blob/master/engineering/git-flow.md

Great to to see available_hardware.md published - awesome list of laptops!

I have a question - does anybody think that getting a different, cost-equivalent, equipment like a monitor, rather than the listed ones could possibly be an option?

I.e a there is almost new rotating Dell P2715Q on sale in one of the mobile market apps in Madrid for ~400e right now (which is 700e new), and it’s very similar to the ones that are already been used in office, but its by far better then ~370e ones from the list.

I understand the benefits of having a single standard for the company, but at the same time having some flexibility could go a long way in productivity and convenience (in case it does not bring many downsides i.e for items that do not have a very long life span).

What do you think?

To have a more uniform documentation, I think the documentation guide should:

• Have a title capitalization style. In the guide itself the 2nd level titles are 'Title Case', while 3rd level are 'Sentence case'
• Specify if we should follow British or American spelling