开源日报 - Page 165 of 262

开源日报第384期：《中国风 zhui》

3 4 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《中国风 zhui》
今日推荐英文原文：《How to Open Source Your Code》

今日推荐开源项目：《中国风 zhui》传送门：GitHub链接
推荐理由：一个中国风的 React UI 组件库，包括卡片，进度条和提示等等。尽管这个组件库的组件种类并不多，但是其风格还是相当有意思，不过要注意的是这个库还在开发中，兴许在开发完成之后会提供更多种类。这个项目是作者在寒假期间所做，当然也从中学到了很多只有实践才能了解到的知识。纸上得来终觉浅，欲知此事须躬行，这句话用在写代码上依然适用。
今日推荐英文原文：《How to Open Source Your Code》作者：Sanjay Nair
原文链接：https://medium.com/@nirespire/how-to-open-source-your-code-6c6274169117
推荐理由：将自己的代码开源的方法
How to Open Source Your Code
In my last post, I outlined what open source is and presented some steps for how to get involved. Every open source project available today, even those with many thousands of contributors, all started with at least one person who had the drive to make what they were creating available for other to freely use and contribute to.

If you fall into this category of people but don’t have a good idea of how to get started, then this is hopefully a good place for you to start. We will cover some of the high level concepts and steps you can take to get your project ready for the world of open source.

While these are my top picks for how to properly prepare a project to be open sourced, this list is by no means exhaustive. The best source for open source is always the community at large. Everything said here is based on my experience participating in open source as well as learning from others maintaining their own projects. After reading, I encourage you to go find one of the many amazing open source projects out there and follow their examples. There are some links at the end to help you get started!
Step 0: Identify the Opportunity
This is more of an optional step but, in my opinion, since open source is all about adding value through collaboration, your first step might be to consider some things about your code.
- Is this something that you got value out of?
- Is this something that you think others would get value out of?
- Do you think more people contributing would improve the quality of what is being provided by the code?
Big disclaimer: these are not questions that necessarily need a “yes” answer to move forward. The answers will mean more or less to your situation. Whether you’re open sourcing your code to get a lot of contributors involved quickly, or just as an exercise to become more proficient in the relevant skills. Just consider how the answers might affect your results.
Step 1: Prep the Code
The baseline requirement for a project to be viable in the open source landscape comes down to the thing that makes open source a concept in the first place: enabling other people to be productive using, modifying, and improving its code. With that obvious requirement, you need to ask yourself a simple question:

If I handed someone this project right now, how hard would it be for them to read the code, run the code, and change the code?

You could follow up on that with:
- Are there any tools that the contributor should install or be familiar with before getting started?
- Does it matter what platform the person is working on (Windows vs Mac vs Linux)?
- How can the person be confident that making a change in one place won’t break something else in the code, i.e are there any tests?
- Is the code well organized and easy to follow?
All of these points are really to say that if you’re going to be putting something out there with the intention of others picking it up and working on it, you should take the necessary steps to set them up with a quality product. There are many books out there that outline some of the best practices for writing good code (Clean Code comes to mind). You might consider handing off your project to someone with technical knowledge but who’s not familiar with it and get their feedback for how easy some basic development task was to complete.
Step 2: README
The README might be the most important document included with a project when it comes to providing a newcomer with the summary of what your project is all about. In addition to a brief summary of what the the code is trying to accomplish, the README is the first place you can answer some of the questions listed above. Someone stumbling on your code should be able to start by going through the README and end by at least being able to understand what the code can do, download it to their machine, and run it.

Try to find some examples of cool README documents from some of the prominent open source projects on Github. As flashy as they are with badges and logos, remember that they all answer the basic questions listed above in some way.
Step 3: The License
The open source license is probably the second most important document you want to include in your project before releasing it out into the wild. In short, since you’re putting your code out there for anyone to see, you probably want to have some control over what people can and can’t do with it once they have it. For example:
- Are you OK with someone using it to run their business?
- Are you OK with someone modifying it and selling it as their own, new product?
- Does the entity using your code need to explicitly give your credit when using any original or modified version of your code?
The good news is, so much of the heavy legal work has already been done by other smart folks on the internet. Github does an amazing job with their helpful documentation as well as reminders when you create a public repo without a license to make sure you include the right one for your needs.

You can drop in a license right when you create the repo on Github!
Step 4: How to Contribute
A set of contributing guidelines is the next important piece of documentation you should include, usually in the form of a CONTRIBUTING document much like the README. The CONTRIBUTING document or set of documents serve to inform the prospective newcomer to your code on how you as a maintainer want them to go about making contributions.

A CONTRIBUTING doc serves to answers some questions like:
- What are some ways I can contribute in the first place? Are you, the maintainer, just looking for bug fixes or new features?
- What’s the first thing I should so when I want to make a change to this code?
- Should I create an issue or just fork and pull request?
- Are there any branching conventions I should follow?
- Should I write my commit messages in a certain way?
- Who are the maintainers aka. who’s in charge here?
- Do you follow any coding styleguides?
Here’s an example of a basic CONTRIBUTING document I came up with:
```
Hello! Thanks for contributing to <Insert Awesome Project Here>

# How to Contribute
Step 1. Please open an Issue with a description of what you're trying to add/fix/change

Step 2. Fork and create a feature branch in the format <some-description>/<your issue number>

Step 3. Please squash all your commits into one with a good commit message before opening a pull request

Step 4. Open a pull request, reference your original issue, and provide a concise description of how your changes fixed the issue

Step 5. Your PR requires 2 approvals from maintainers before it can be merged.
```
You can go as wild as you want with it. Just like the code, all the documentation is also open source, so it can also evolve and improve along with your project! Check out Github’s documentation for some amazing examples of contributing documents in the wild. I particularly like the short and sweet Open Government Contributing guidelines document.
Step 5: Community
Open source is at its best when you have a strong community behind it. Whether is just you and a couple of maintainers, or a project that you foresee spanning hundreds of contributors, it’s important to set a precedent for the spirit of collaboration you want to establish around your projects.

While documentation like the README and CONTRIBUTING guidelines could also touch on this subject in some ways, the CODE OF CONDUCT is where you should be most direct about how you expect people to behave and interact with each other.

People might not be explicitly asking the questions that the code of conduct document seeks to answer, but it can always be there to set a baseline standard of conduct if issues were to ever arise. Some of these implicit questions might be:
- Are contributors expected to converse with each other as if they were in a professional setting like an office, or is the tone more informal?
- What are some of the core values someone should adhere to when approaching interpersonal interactions within the community?
- What should someone do if they notice someone behaving inappropriately within the community?
- What, if any action, would be taken if someone were to break the etiquette rules?
Here’s an example of the simplest code of conduct document I thought up.
```
Code of Conduct

- Be kind
- Be welcoming
- Don't be a jerk
```
Feel free to copy if you find it helpful!

But in all seriousness, there are lots of great examples available to reference just like all the other documents. One example is Facebook’s Open Source Code of Conduct which they link to in all of their open source project repos.
Step 6: Consistency
Making sure your open source project is successful and productive depends, just like any other project, on you giving it the appropriate amount of time it needs to succeed. This could include simple actions like regularly updating dependencies on major releases, or going through all the open Issues and Pull Requests at least once a week. It’s always better to have someone come across your repo and see commits and merged PR’s that are a few days old rather than a few weeks or months old.

For larger projects with many users and contributors, it might mean making sure you’re being responsive to emails or messages. A common practice among larger open source projects is to have a public instant messaging platform like Slack available for anyone with questions or suggestions to join the community discussion about the project.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第383期：《不需要 V2.0 You-Dont-Need-jQuery》

2 4 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《不需要 V2.0 You-Dont-Need-jQuery》
今日推荐英文原文：《Getting Started With Open Source》

今日推荐开源项目：《不需要 V2.0 You-Dont-Need-jQuery》传送门：GitHub链接
推荐理由：这次的不需要是关于 jQuery 的，介绍了一些方法用来代替它所实现的某些功能，比如各种元素的查询， CSS 属性调整和动画等等。如果说之前写网页的时候照葫芦画瓢的使用了 jQuery，借这个机会用自己的方法实现从而达到融会贯通是一个不错的主意。而这个项目提到的新的方法也可以作为除了jQuery之外的选择用于之后的项目中。
今日推荐英文原文：《Getting Started With Open Source》作者：Sanjay Nair
原文链接：https://medium.com/@nirespire/getting-started-with-opensource-74e963db32f5
推荐理由：在代码上为开源贡献的第一步
Getting Started With Open Source
Did you know that a large part of the software you use everyday was probably built with tools and technologies that are freely available for anyone to download, install, study, and modify?

The operating system running the server that’s delivering this webpage to you. The library securing your network traffic to this website. The framework used to build this website. All of these thing were build on or with the help of open source technology.

Software being open source means that not only is all of its source code available to download and view publicly, but its also available for anyone to modify and contribute back to. In fact, a lot of the success of open source software by definition is dependent on volunteers contributing changes and collaboratively making the software better.

Contributing to someone else’s codebase might seem like a daunting proposition, but all you really need is a computer connected to the internet and a desire to dive into the deep end of an interesting problem you want to contribute your time to.

In this piece, I hope to shed some light on the specifics of how to approach getting started with participating in open source.
Step 1: Go to the Source (Code)
There’s no “official” platform or methodology used by the open source community to get their work done. That being said, today most of it is done on Github. There are other git-based alternatives like Gitlab and Bitbucket and even some that are not git-based at all. The Linux Kernel is one of the largest and most active open source projects to date and it is entirely managed through emails of code patches! However, Github is currently the most popular open source platform and is very easy for beginners to get started with.

Github is a place for people to upload their code and have it viewable by the public or privately. Public code repositories or “repos” have many features that make it easy for anyone with some basic knowledge of the software in question to contribute their efforts to making the product better in some way. Not every contribution even needs to be technical in nature. Lots of contributors spend their time moderating dialogs or creating and managing documentation.

A good first step would be to create an account there, if you haven’t already, and get familiar with navigating around the site. Check out the trending page for a list of public code repos getting a lot of attention on any given day. Click through some of the different tabs on each repo and explore around. Check out the Issues tab to see what sorts of discussions people are having about the problems they are encountering with the software and how the community has responded in discussion threads. The Pull Requests tab typically has examples of how people have contributed to fixing outstanding issues or added new features.

Most of the remaining steps in this piece will deal with navigating around Github, so make sure you’re comfortable with it!
Step 2: Find Something to Contribute To

“Necessity is the mother of invention”
Sometimes the hardest part about getting into open source is finding a project or initiative that you can connect with or are inspired to contribute to. Sometimes you need to go out and find it, and other times it falls right into your lap as a problem you need to overcome. If you work with code and software a decent amount, chances are you ran into some feature you wished was there or a bug you really wish wasn’t there.

One example of this comes from an issue my team ran into at work: We had multiple code repos on Github with many team members all making changes and submitting requests to have those changes be reviewed before they were deployed. We needed a way to concisely display all the open changes that needed review for our code repos. After some googling, I found the Github PR Dashboard, which quickly solved our problem. After using it with the team and getting great value from it, we eventually contributed back some features and enhancements for others to use. Check out my past contributions!

If you don’t have an existing desire to fix or improve something already, there are some great resources available to get you pointed in the right direction. Your First PR is a project specifically aimed at highlighting opportunities for beginners to contribute to open source projects. There’s a great talk from the React NYC conference on how someone used this resource to contribute code to the React JS codebase which is currently one of the most popular web development tools used today.

Hacktoberfest is another great initiative around getting folks into open source. Every year during the month of October, companies who maintain open source projects encourage new contributors to submit changes for the opportunity to win real-world prizes like T-Shirts and stickers. Any organization is open to participate in this event and each has their own guidelines for how to contribute and win prizes. When October rolls around, be sure to keep an eye out for Hacktober opportunities popping up!
Step 3: Do Your Homework!
Now you have something you want to contribute to, what’s next? Well the answer is: it depends. Your open source search might have landed you in a small and simple codebase like some student’s side project, or something way more complex and far-reaching like a multi-faceted project backed by hundreds of other contributors and used by multi-billion dollar companies. Both types of repos will have different levels of quality and guidelines on how to contribute.

The best place to start to figure out where to start is the README. Any good open source project should have a good README. Good might mean different things to different people, but you can judge that for yourself. Here are some basic things to look for:
- Does it have a concise and informative description of what the project is at a high level and what problem it is trying to solve?
- Does it have instructions on how to set up the project on your machine for development?
- Does it link to any additional documentation that would be helpful to someone trying to make changes to it?
You can find great examples of READMEs in some of the larger open source projects like React, VSCode, Tensorflow, and more. Use the details in this document to get more familiar with what the repo is all about. Try to follow the getting started steps to clone the code locally and get it up and running.

Next thing to look for is a CONTRIBUTING document. Where the README might include the what and why, the CONTRIBUTING document tells you the how.
Sometimes these details might be included in a README section, so don’t worry if you don’t find this specific document.
What are the guidelines that the repo maintainers have put forward for how they want you to make changes to the code? Sometimes it’s as simple as opening a pull request and having someone approve and merge it. Larger projects might have stricter protocols that include opening an issue, validating the issue is not a duplicate, opening a pull request, having the pull request pass automated test suites or CI process, and finally being approved by a maintainer. Different projects operate in different ways, so be sure to know how the one you want to contribute to does.

The VSCode project has a great CONTRIBUTING document that I’ve always been directed to as a reference.

Last but certainly not least is the CODE OF CONDUCT document. This document provides the guidelines by which contributors are expected to conduct themselves when collaborating online with the community. Some can be short and sweet and simple say “Don’t be a jerk.” Others can get into more details about what kind of interactions and behavior are considered inappropriate.

The Angular project has a short and sweet code of conduct that get’s right to the point very effectively.
Step 4: Fork and Code

Disclaimer: These next two sections assume you know the basics of Git including common operations like how to clone, branch, commit, merge, and push.
Now you’ve found some code you want to contribute to and you’re familiar with the process put in place by the maintainers to do so. Next we’re going to get into the nitty-gritty details about how to make your changes and actually submit them.

Github has a feature called “forking” that essentially means: take this repo owned by someone else and create a linked copy in my personal Github profile.

The github-pr-dashboard owned by joeattardi that I forked to my profile

This allows you to create a branch and push code to your forked copy without having write access to the main repo.

So now you should do exactly that. Clone the forked repo to your machine, make whatever changes you planned, and commit to a branch on your forked repo. If applicable, follow any branching, code style, and testing requirements outlined in the contributing guidelines.
Step 5: Open a Pull Request
Once you’re happy with the changes, you can open a Pull Request.

One way you can open a PR is clicking this button on the Pull requests tab of your forked repo

Make sure that the base branch you are proposing to merge your branch into is the appropriate branch of the original repo. That way the maintainers will see your open PR in their list of pull requests.

Again, follow the contributing guidelines to decide which is the correct default branch the maintainers want you to merge into and what details are expected in the Pull Request description. Some repos on Github are set up with Pull Request templates that will pre-fill the description with a basic scaffold you can add details too.

Now just wait to get some feedback from the code owners to see if they think your changes are ready to be merged. Sometimes its a quick thumbs up and other times there might be some back and forth where additional changes might be requested. Remember that this whole process is about teamwork and communication. You the contributor and the maintainer are on the same team, so be sure to respect the code of conduct for contributing and don’t get discouraged if you don’t get it right the first time!

Once that’s done, you did it! You have officially contributed to open source!
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第382期：《现在是 XP 时间 winXP》

1 4 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《现在是 XP 时间 winXP》
今日推荐英文原文：《Meetings that make people happy: Myth or magic?》

今日推荐开源项目：《现在是 XP 时间 winXP》传送门：GitHub链接
推荐理由：小的时候相信大家都或多或少的用过 XP 系统，这玩意虽然看起来外观并不能算太华丽，但是已经足以满足日常需求了。这个项目就是个基于 Web 的 XP 系统桌面，你可以拿它玩玩扫雷之类的来回忆一下童年时光，还有那个熟悉的草原背景和界面画风，虽然它并不能做到太多的事情，不过就这么看看也挺不错的。
今日推荐英文原文：《Meetings that make people happy: Myth or magic?》作者： MaryJo Burchard
原文链接：https://opensource.com/open-organization/18/8/7-questions-engaged-meetings
推荐理由：如何举行吸引人的会议——毕竟以后不少人可能会经常参与或是主持会议
Meetings that make people happy: Myth or magic?
People tend to focus on the technical elements of meeting prep: setting the objective(s), making the agenda, choosing a place and duration, selecting stakeholders, articulating a timeline, and so on. But if you want people to come to a meeting ready to fully engage, building trust is mission-critical, too. If you need people to engage in your meetings, then you’re likely expecting people to come ready to share their creativity, problem-solving, and innovation ideas.

All these things require taking risks—and risks force people to be vulnerable. Trust is therefore fundamental to getting anyone to engage meaningfully in meetings. But trust is not unilateral. If you think people either “trust you or they don’t,” you’re missing important opportunities to help people feel free to bring everything they have to engage in your meetings.

Let’s look at seven questions open leaders can ask themselves as they get ready to gauge and build trust levels in advance of their meetings. The extent to which you’re able to do this can make or break constructive engagement in meetings.
1. Are you for real?
Engagement begins with people’s need for confidence. First and foremost, they’re going to want to know that the meeting they are walking into will be exactly what you told them they’d be walking into. They want to be able to rely on and accept the accuracy of your stated reason for the meeting, its objectives, etc., at face value, knowing that you are not intentionally attempting to deceive or trap anyone, nor are you withholding crucial information from them.

When people can trust your authenticity and they know you’ve shared exactly what they’re getting into, they can prepare themselves accordingly. Blindsided people may be reticent to participate at the same depth.
2. Are you safe?
Few things are more daunting than the fear of walking into an ambush. When people wonder if their input will cause someone to be thrown under the bus—or worse, when people fear that problem-solving or brainstorming sessions will turn into a dogpile or blame-fest—you can bet that the only people who will be excited to engage are the people who enjoy being abusive, calling it “collaboration.” Contrary to what some in the open source community seem to believe, intentional use of caustic, demeaning expressions for “feedback” will not produce the highest quality outputs.

What the team will end up with instead is an unwritten rule that the most oppressive voices always win; other brilliant ideas will be stifled when the people who have them do not feel personally safe to share them. With the exception of people who enjoy the cathartic rush of harsh exchanges, openness to genuine feedback occurs when people do not fear that they will be personally attacked or publicly humiliated in the process. For the strongest possible engagement in meetings, set clear group expectations that balance candor and transparency with enforced communication and behavioral norms that promote confidence rather than intimidation.

When people can trust you to model and reinforce threat-reducing behaviors during collaboration and idea sharing, you make room for a true meritocracy of ideas to emerge.
3. Are you consistent?
One of the greatest gifts a leader or decision-maker can give to stakeholders is a clear sense of consistency. Consistency enables people to obtain some level of clarity regarding the range of possibilities for any given meeting—and it helps them plan accordingly.

When people can trust your words and actions to have clear, reliable patterns, they can gain a clearer sense of their role in the engagement process.

Even if people are not fond of your predictable behavior, they can learn to navigate their own responsibilities around what they know you will say or do. As an added bonus, in your absence your consistent behavior will still enable them to engage in making decisions about which they can confidently predict your general thoughts and responses.

When people can trust your words and actions to have clear, reliable patterns, they can gain a clearer sense of their role in the engagement process.
4. Can they depend on you?
Somewhat related to consistency is your reputation for being a person of your word. I have facilitated countless decision-making meetings in organizations that began with the question, “Is this going to be another one of those meetings where we do all the hard work and come up with a workable solution, and then the powers that be are going to just do whatever they want anyway?” Past failures to follow through can destroy people’s motivation to attempt to engage again. If a history of undependable follow-through and unkept commitments exists (whether or not you were at the heart of them), acknowledge the failure to the people in advance and discuss with them the measures you will take to keep the current commitments related to this new meeting.

When people can trust your word to follow through on commitments related to their investment in the meeting, they can often give the process another chance, even if others failed to follow through in the past.
5. Do you know your stuff?
Having the skill and expertise to conduct the meeting and discuss responsibilities isn’t enough. You need to know your people. A meeting in which the leader is unfamiliar with the group’s history, trigger words, social cues, behavioral norms, and shared values will make it very difficult to make sure you (and others!) are engaging in alignment with cultural expectations. Perceived incompetence by the person leading a meeting can be an immediate engagement-killer.

When people can trust that you know what you are doing, they can relax and focus on their own responsibilities in the meeting.

If you are new to the group, before the meeting (or as an opening session), let the people help you catch up with discovery discussions (individually or in small groups), and ask them for help in understanding the shared story, values, history, norms, etc. in addition to any nuanced skills or knowledge you’ll need to grasp to facilitate effective discussions.

When people can trust that you know what you are doing, they can relax and focus on their own responsibilities in the meeting.
6. Does the buck stop with you?
With complex or wide-scale projects, it’s easy for things to fall through the cracks. People you work with are likely heavy hitters who already want to do a good job—but someone has to assume ultimate responsibility for the success of the entire team. I’m not talking about ultimate “fault” or “blame” in case something goes wrong (we want solutions, not human targets). I’m talking about ownership. Someone needs to assume personal responsibility to help set up the task/project/team for success, and own any initiative that needs to be assumed if it begins to flounder. If you assume ownership, you embrace the responsibility to engage with the stakeholders holistically and proactively. Your words and actions will hold you and everyone else to the highest possible standards.

When people can trust that you assume personal responsibility and ownership of helping them succeed, the mental and emotional energy they’d commit to self-protection “just in case you drop the ball” can be redirected to bolstering their own contributions.
7. Do people believe that your intent is to help?
This is the linchpin of trust.

People can handle a lot of things—inconsistent or erratic behaviors, stupid verbal responses, lack of follow-through, even lack of knowledge or ownership—if they can sense that you are really trying to do right by them. It is worth the time to connect with people beyond what you need from them, to take a genuine interest in who they are as people and what’s going on in their lives. Beyond being good interpersonal protocol, it’s good business.

When people are inclined to believe what you say and do is intended to help and not harm them, they will be more likely to interpret and respond to your failings to have the best possible motives, which often means they’ll engage with you to help work through the kinks even if they are frustrated or even angry with your behavior.

Bottom line? Trust is where engagement begins, in meetings and in life. Understanding the multiple dimensions of trust gives us the opportunity to have conversations that can help us build it up wherever it is lacking—before we need it in the meeting.

For example, when we allow someone to tell us, “I trust that you mean well, but I do not yet trust your competence in this skill,” or “I trust your expertise and I know you intend to do what you say, but I find that your optimism about what can be done in an hour exceeds reality, so despite your good heart, I cannot currently trust your dependability,” we have a chance to pinpoint what areas we need to foster their trust. Responding to statements like these with questions like, “What do you need from me in order to grow in your trust of me in this area?” and then following up to track your progress can also add to others’ perception of your intent to do them good.

Stay with it! Over time, both trust—and with it, engagement—will grow.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第381期：《简单传递 send》

31 3 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《简单传递 send》
今日推荐英文原文：《Why do organizations have open secrets?》

今日推荐开源项目：《简单传递 send》传送门：GitHub链接
推荐理由：这个项目允许你很简单的通过浏览器传递一个文件——把你的文件上传，然后把链接给别人拿去下载，就可以实现文件的传递。文件的发送经过了加密，虽然一些移动端浏览器并不支持它们的加密方式，但是这能够保证足够的隐秘性；而你也不需要担心文件会存在于可能会不安全的地方太久，在一定时间或者到达下载限制之后上传到服务器的文件就会被销毁。
今日推荐英文原文：《Why do organizations have open secrets?》作者：https://opensource.com/open-organization/19/3/open-secrets-bystander-effect
原文链接：https://opensource.com/open-organization/19/3/open-secrets-bystander-effect
推荐理由：“兴许每个人都知道这有问题，但是他们没有说出来，其中肯定有什么我不知道的原因，我最好也不要说”
Why do organizations have open secrets?
The five characteristics of an open organization must work together to ensure healthy and happy communities inside our organizations. Even the most transparent teams, departments, and organizations require equal doses of additional open principles—like inclusivity and collaboration—to avoid dysfunction.

The “open secrets” phenomenon illustrates the limitations of transparency when unaccompanied by additional open values. A recent article in Harvard Business Review explored the way certain organizational issues—widely apparent but seemingly impossible to solve—lead to discomfort in the workforce. Authors Insiya Hussain and Subra Tangirala performed a number of studies, and found that the more people in an organization who knew about a particular “secret,” be it a software bug or a personnel issue, the less likely any one person would be to report the issue or otherwise do something about it.

Hussain and Tangirala explain that so-called “open secrets” are the result of a bystander effect, which comes into play when people think, “Well, if everyone knows, surely I don’t need to be the one to point it out.” The authors mention several causes of this behavior, but let’s take a closer look at why open secrets might be circulating in your organization—with an eye on what an open leader might do to create a safe space for whistleblowing.
1. Fear
People don’t want to complain about a known problem only to have their complaint be the one that initiates the quality assurance, integrity, or redress process. What if new information emerges that makes their report irrelevant? What if they are simply wrong?

At the root of all bystander behavior is fear—fear of repercussions, fear of losing reputation or face, or fear that the very thing you’ve stood up against turns out to be a non-issue for everyone else. Going on record as “the one who reported” carries with it a reputational risk that is very intimidating.

The first step to ensuring that your colleagues report malicious behavior, code, or whatever needs reporting is to create a fear-free workplace. We’re inundated with the idea that making a mistake is bad or wrong. We’re taught that we have to “protect” our reputations. However, the qualities of a good and moral character are always subjective.

Tip for leaders: Reward courage and strength every time you see it, regardless of whether you deem it “necessary.” For example, if in a meeting where everyone except one person agrees on something, spend time on that person’s concerns. Be patient and kind in helping that person change their mind, and be open minded about that person being able to change yours. Brains work in different ways; never forget that one person might have a perspective that changes the lay of the land.
2. Policies
Usually, complaint procedures and policies are designed to ensure fairness towards all parties involved in the complaint. Discouraging false reporting and ensuring such fairness in situations like these is certainly a good idea. But policies might actually deter people from standing up—because a victim might be discouraged from reporting an experience if the formal policy for reporting doesn’t make them feel protected. Standing up to someone in a position of power and saying “Your behavior is horrid, and I’m not going to take it” isn’t easy for anyone, but it’s particularly difficult for marginalized groups.

The “open secrets” phenomenon illustrates the limitations of transparency when unaccompanied by additional open values.

To ensure fairness to all parties, we need to adjust for victims. As part of making the decision to file a report, a victim will be dealing with a variety of internal fears. They’ll wonder what might happen to their self-worth if they’re put in a situation where they have to talk to someone about their experience. They’ll wonder if they’ll be treated differently if they’re the one who stands up, and how that will affect their future working environments and relationships. Especially in a situation involving an open secret, asking a victim to be strong is asking them to have to trust that numerous other people will back them up. This fear shouldn’t be part of their workplace experience; it’s just not fair.

Remember that if one feels responsible for a problem (e.g., “Crap, that’s my code that’s bringing down the whole server!”), then that person might feel fear at pointing out the mistake. The important thing is dealing with the situation, not finding someone to blame. Policies that make people feel personally protected—no matter what the situation—are absolutely integral to ensuring the organization deals with open secrets.

Tip for leaders: Make sure your team’s or organization’s policy regarding complaints makes anonymous reporting possible. Asking a victim to “go on record” puts them in the position of having to defend their perspective. If they feel they’re the victim of harassment, they’re feeling as if they are harassed and being asked to defend their experience. This means they’re doing double the work of the perpetrator, who only has to defend themselves.
3. Marginalization
Women, LGBTQ people, racial minorities, people with physical disabilities, people who are neuro-atypical, and other marginalized groups often find themselves in positions that them feel routinely dismissed, disempowered, disrespected—and generally dissed. These feelings are valid (and shouldn’t be too surprising to anyone who has spent some time looking at issues of diversity and inclusion). Our emotional safety matters, and we tend to be quite protective of it—even if it means letting open secrets go unaddressed.

Marginalized groups have enough worries weighing on them, even when they’re not running the risk of damaging their relationships with others at work. Being seen and respected in both an organization and society more broadly is difficult enough without drawing potentially negative attention.

Policies that make people feel personally protected—no matter what the situation—are absolutely integral to ensuring the organization deals with open secrets.

Luckily, in recent years attitudes towards marginalized groups have become visible, and we as a society have begun to talk about our experiences as “outliers.” We’ve also come to realize that marginalized groups aren’t actually “outliers” at all; we can thank the colorful, beautiful internet for that.

Tip for leaders: Diversity and inclusion plays a role in dispelling open secrets. Make sure your diversity and inclusion practices and policies truly encourage a diverse workplace.
Model the behavior
The best way to create a safe workplace and give people the ability to call attention to pervasive problems found within it is to model the behaviors that you want other people to display. Dysfunction occurs in cultures that don’t pay attention to and value the principles upon which they are built. In order to discourage bystander behavior, transparent, inclusive, adaptable and collaborative communities must create policies that support calling attention to open secrets and then empathetically dealing with whatever the issue may be.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/