Teams exist to avoid individual uncertainty.

I wrote this article for about 10 days, 1-2 hours a day, thinking and writing. It’s a lot of stuff, and it might be messy, but I feel like there’s no crap. So, if you are interested, please spend some time reading patiently.

WangEditor (V4.0) – typescript rich text editor for the Web. It is lightweight, concise, easy to use, open source and free.

(PS: original addressJuejin. Cn/post / 688252…, shall not be reproduced without the permission of the author)

Thank you

First of all, I would like to thank the entire team for their support and trust in wangEditor. As of this post, the team is 11 people (including me). As the organizer of the team, I feel very pleased that everyone can join the team for free and contribute code at the expense of their spare time. Thank you!

In addition, want to join the open source team, through QQ group, direct contact group owner. Pass some tests and you can join.

Participate in open source to increase your community awareness and interview competitiveness. In wangEditor team, you can experience dachang standard agile RESEARCH and development process, multi-person collaborative development, independent technical scheme design, strict code walking.

background

WangEditor is an open source project I started many years ago. I looked at my own blog at the time and it was published in late 2014.

Then, I maintained it all by myself. With my energy at that time, I rebuilt and upgraded V2 and V3 versions. Code to write, document to write, QQ group and github issues to manage their own. I learned a lot during that time, but I did get more and more distracted.

Especially in 2017-2018, I really have no spare time, so I stopped maintenance. So, before V4 was released, the github code was updated 2 years ago. To this I can only express very helpless, unwilling, but there is no way.

I left Didi in the spring of 2020 and had more free time. I wanted to start the project again, so I worked on it for a few months until the current V4 release.

Before I did, though, I thought about the biggest problem with being forced to stop maintenance — being too dependent on my personal energy. At this point, many people may sigh “Ah, open source is not easy!” And then nothing happened. But I still want to give it a try — I can’t do it alone, SO I’ll build a team.

It’s not just about making open source products

From the moment I decided to “recruit,” I had two goals.

  • Build the wangEditor V4 version and continue to maintain it. This is not difficult to understand, do open source is such.
  • Explore how wild open source projects (not big factory projects, not star projects) are developed and maintained by teams, and this is a priority!

Perhaps out of my ignorance, I have not yet seen a wild open source project developed and maintained by a team. Even if they do, for example, they have multiple administrators in their QQ group who can help answer questions. But also did not see who can output the experience of this respect, for my reference to learn.

Since there isn’t (or there is, and I can’t find it), I’ll do it myself. I also took the PMP examination, and I know a little about R&D project management. I’m doing a small contribution to open source by finding out for myself, even if it’s a little bit of a lesson or experience, and exporting it to the community.

I hope that, in the future, more and more projects will also be maintained by teams rather than individuals. A person to do open source, too hard!

Why am I doing open source

Open source has been a perennial question for many years, and there are two main answers:

  • Feelings level, craftsman spirit, output their own value for the world
  • Practical level, increase their competitiveness, in the interview more chips

The above two reasons are applicable to everyone, and I am certainly one of them.

But I want to say, from my own personal situation, some of my own ideas, may not be general, but it doesn’t hurt to have a look.

First, to maintain the ability to code a line

I haven’t worked since I left Didi. I want to experience a freer lifestyle while I’m still young. The joy of life lies in different experiences. Of course, I’m a restless person and can’t play every day. I don’t even own Douyin, and I can’t play games.

I’ve been doing online courses on the side, and I’m still doing it. But always do the course, not the first line of coding, slowly coding ability will decline. So I had to have a way to maintain my coding ability. Open source is the best way.

In such a fast-paced environment, crisis awareness cannot be relaxed.

By the way, I want to say two words of nonsense and express my feelings

  • With the development of online education for many years, the current online courses are no longer just a simple matter of “making an e-commerce project with Vue”, but have reached the level of real projects, online businesses and solutions. I’m taking a course where the complexity of the project is very high.
  • Based on my own sense of crisis, you can compare it to the lecturers who teach full-time, but have no other output, will they, as I said, slowly decline in coding ability? — I don’t know. I’m just talking about myself.

Second, strive to do a fine subdivision field

Remember the two sentences I read before, forget where I read from.

  • First sentence: Don’t go for cutting-edge technology, complex frameworks, but think, what can you do with existing technology? Even if it only affects a small number of people.
  • If you can make a product that can be used by others, you’ve already surpassed 90% of the programmers in the world

In my opinion, these two words influenced my values at that time, making me gradually shift from a purely technical thinking to a business and product thinking.

If you ask: who are the most skilled people in the software/Internet industry? There will be a lot of people who will answer: the author of xx framework, the author of XX blog, the person who knows XX to answer the question, the person who can read the source code of the framework…… Can ask the people around me, I believe there will be a lot of people who answer this way.

But I would say that the most skilled people in the industry are never the ones who just focus on technology, but the ones who can apply technology to products and businesses, and solve business problems through technology. Technology itself does not generate commercial value. It is the products developed by technology and the services provided by the products that generate commercial value and pay us salaries and bonuses.

Therefore, I encourage you to learn knowledge at a level of granularity that meets normal development needs. Don’t pay too much attention to weird algorithms, cutting-edge technologies, framework details, “10 ways for Vue components to communicate” — is that really necessary? (PS: Ignore this paragraph if you are preparing for an interview, but preparing for an interview is only temporary.)

Moreover, this is an age of rapid progress and increasingly sophisticated technology. What you need to know now may be a solution in two years. For example, in two years no one will go back and ask you how webPack is configured. Technology advances at high speed, also eliminated at high speed, do not rush to this highway when cannon fodder.

In my view, we cannot remain competitive in any industry for long through purely technological means. The older you get and the more experience you have, the less valuable your skills become. On the contrary, the ability to solve business problems through technical means, the ability to solve solutions, the ability to integrate resources, will become more and more important. This kind of ability can not be mastered by looking at code, reading books or watching videos. It takes a lot of time to accumulate and even requires active trial and error.

The rich text editor is the counterpart of the online Office business, which is growing rapidly. Now you buy a new computer, do not have to install Windows Office, direct use of off-the-shelf Tencent documents/graphite documents on the line, very convenient.

If I study the whole online Office system, it is not realistic, I do not have the environment, I do not have any advantages, and the scope is too large, I also have limited energy. Rich text editors, with their peripheral solutions such as collaborative editing, are just right for this.

The development and maturity of an industry will inevitably bring about a fine division of labor in the field. It’s professionals doing professional things, working together, rather than one company doing everything. This is the law of nature. So, seize a fine field, good research, believe there will be opportunities in the future.

Another purpose of the team

Teams exist to deal with individual uncertainty, which makes the business run more reliably. So companies exist as teams. In the same way, I build teams to maintain open source projects in order to keep the development and maintenance of the project stable, rather than relying solely on my own energy.

But beyond that, I have another purpose, which is about my personal growth and transformation. I used to work as a programmer and make my living with technology. Although this bowl of rice is still delicious, but also in times of peace to be aware of danger (but do not make too anxious, or even depressed ~). It’s like the hot topic of “career after 35” on the Internet.

I always believe that no matter what industry technical personnel, from graduating from university to about 30, is a stage to accumulate personal technical ability and experience, and it is no problem to rely on technology to make a living. After 30, consider the transition: personal ability > resource integration ability.

Resource integration capability comes in many forms, and different people have different views on it. In short, don’t do it alone, but gather a group of people and work as a team, whether it’s full-time or part-time. My job is to make this team work, and work steadily, consistently, efficiently and rhythmically. There is no set standard. It has to be honed through practice.

I set up this team because I want to practice my ability to arrange resources. It’s also a lot of challenges for me.

  • In the product business, I participate in discussions, review requirements, and make sure it’s easy to use
  • technical
    • First, design the overall framework, build the development and test environment, CI/CD process, and try to make everyone pay attention to business development
    • Second, the formulation of coding standards, research and development standards, development documents and so on, many people without rules will be chaotic
    • Third, review the technical scheme design to ensure the rationality and scalability of the design, and strictly review each pull request and conduct code review. Do a good job every time, otherwise it is easy to have the “broken window effect”
  • In terms of project management, there are many tasks carried out in parallel, which should be orderly, without conflict and without delay
  • In terms of team building, I will recruit and assess new members, be a new member, formulate team discipline and norms, and regularly communicate with members 1-1 to ensure that there is no misunderstanding in cooperation
  • In terms of future planning, think about what you want to do in the next year

That’s all I can think of right now, after all, I’ve only been doing it for a few months. I believe there will be new content to supplement, then I will continue to produce the article.

So many things, I believe will bring more comprehensive growth. Although open source is not profitable, it is not idle work, it generates value. I believe that as long as it is value, there will be an opportunity to cash in one day in the future.

Team building

Let’s do some dry work, write about the process of building a team and doing a project.

Why join a team for free?

The article begins by thanking all the members of the team, who join the team for free and contribute code every night and weekend. So why do people join teams? That’s a question I have to think about. That is, what is the appeal of the team and what is not doing well.

When I communicated with all the members 1-1, I specifically asked this question: What is my expectation of joining the team? What skills do you want to improve through the team?

The answers of all members are quite consistent. Probably the project in the company is relatively simple, all of them are doing business, and I want to improve my ability through an open source project. There are several members who have not graduated, or are in the internship, also want to increase their own project experience through this. The other one is a big factory employee, because I just joined the company, I haven’t had a chance to talk 1-1.

We should not be very detailed thinking about this problem, in the end there are specific points, can improve their coding ability. But it doesn’t matter, at least from now on, the team atmosphere is more harmonious, everyone’s output is more positive, the cooperation is very happy. The assigned tasks can also be actively responded to, and members who have not found communication difficulties.

I remember one member of my team saying he grew more in two months than he did in a year. Who said I forget, if you see it can comment on the reply below.

Let me summarize for you where joining an open source team might help you grow. (PS: There is a background that needs to be mentioned in advance. The current members of our team are mainly employees of small factories, interns and students who have not yet graduated. However, they were recruited after interview and assessment. I’ll write about this later. Take your time.)

  • Agile R&D process. R&d project management is very important in software.
  • Technical scheme design. I used to write code when I needed it. Now it is necessary to write the technical solution design document first, and then write the code after passing the review.
  • Strict code walkthroughs. At present, I do strict code walk-through for every pull request to prevent window breaking effect.
  • Multi-person collaborative development. Before I may be a person in the company to do, do not know how to cooperate with many people development.
  • Document awareness. We have our own knowledge base, all the documents, all the forms, all the accumulated knowledge.
  • The sense of accomplishment of doing open source projects. Some members said that he participated in the project, other colleagues in the company know, he has a great sense of achievement.

With the release of V4.0, there will be more and more things for everyone to participate in. Later, we will also participate in the operation and maintenance work, such as QQ group q&A, Github issues reply and record, product iteration and upgrade, and research on new technology solutions.

That is, before the release of V4.0, we are involved in the development of a single function, and after the release of V4.0, we are involved in the operation and maintenance of a complete product. From single-function development -> product operations to a higher dimension.

Recruit new members

From the beginning of recruitment, up to now, a total of 13 people have been approved. One of them joined and then quit, and two of them didn’t join after they passed the test. I won’t go into the details. So, there are now 10 of us, and with me, 11 of us. Of course, the numbers may change as you read this.

Recruitment channels

  • WangEditor two QQ group announcements.
  • Post announcements on the wangEditor website and documentation.
  • Others introduction

Interested members, join QQ group, and then private chat group owner (is me), interview assessment. After all, we don’t recruit many people, so we can chat manually, we can deal with it.

The interview assessment

After QQ contacted me, I said nothing, first sent a task in the past. The task is basically to develop a simple rich text editor from scratch using WebPack and TS, put the code on Github, and write a blog post documenting the development process. Within a week.

Here’s where it gets interesting. I said that I had recruited 13 people, but I estimated that there were about 50 people who sent me QQ messages. That is, most people give up on their own in this round. Really is their own to give up, I did not take the initiative to reject a person. Even if his task is not done well, I will guide him to continue to finish, rather than reject him.

I’m glad I did it this way, rather than by phone or video interview. The interview is a question and answer, not a test of initiative and hands-on ability. We are an amateur part time team, rather than technical ability, we need to be active, self-driven and hands-on. So, if you don’t want to do, or can’t do, and don’t want to take the initiative to learn and query, then you’re not going to be able to do development on the team.

After that, as long as I pass the assessment, I will arrange to check part of our development documents github.com/wangeditor-… On Github, it’s public. And stressed, to look carefully, look carefully, not fast, read the initiative to contact me. It’s all about self-awareness, because the documentation doesn’t look good, and the development will get in the way.

There’s a lot of emphasis on initiative. Reach out to me when you’re done with tasks, and reach out to me when you’re done with documents. If you don’t make the first move, I’ll take that as giving up. Because, at this time you do not take the initiative, that in the future into the team development task, will not take the initiative.

Wait to see the document, basically determine the completion of the assessment. Talk again, get some basic information.

To join the team

This step is easy

  • Pull into the wechat group (later consider turning tack), and other members of the group to say hello
  • To github.com/wangeditor-…
  • Pull to TeAmbition, here is all task management
  • Pull up the speaker, and this is the project repository, where all the documents are

Self-training for new members

Joining a team is the same as joining a company. The first step is new employee training. However, large companies will explain corporate culture and values in the training, while our team is not at that level yet. We just learn and understand some norms, systems and disciplines.

Also, we are training ourselves, that is, watching for ourselves, no one tells you. If you have questions, ask them. Or take the initiative)

I have a new Employee Self-training Manual in the language, which lists all the code guidelines, process guidelines, communication guidelines, team discipline, etc. In summary, this is the basic information you need to know when working in a team.

Since it is self-training, how to judge whether to finish reading it? The simplest way to do this is with the usual punch-in mechanism. After new members read the training manual, write a clocking record and send it to the group.

The last sentence of the training manual is “When all the above steps are completed, take the initiative to contact the mentor and begin to claim development tasks”. Still want to take the initiative, everything is self-driven.

Team discipline

  • The biggest problem with part-time remote cooperation is communication
  • The biggest problem with multi-team collaboration is regulation

So, team discipline revolves around those two things — communication and discipline.

Communication discipline

  • All communication should be foolproof, that is, speaking plain English so that others can understand, even if they repeat a few sentences. This is very important. Sometimes when you say a few words, you think others understand, but in fact they don’t, so you have to ask back, and then you go on explaining, wasting time.
  • All communication about yourself should have a reply, that is, back and forth. Otherwise, no one will know if you really got it.
  • It was sent from a wechat group[Notice to all staff]All members must respond to the initial message. Do not require seconds back, at least 12 hours to reply. To be honest, this point is not well implemented, every time we send [notice to all], about half of the people can reply. At this point I will continue to figure out how to improve the process.

Specification of discipline

No rules, no fangyuan, all in accordance with the language sparrow to write the development specifications and process specifications, can not create specifications, can not skip any necessary process!

If you think the specification is unreasonable, you can bring it up and discuss revising the specification again. If you need to skip a process in special cases, you need to report in advance.

I spent a lot of time writing specifications before I even had a team. Please share the details of these specifications when you get the chance. This article is full and won’t go into details.

Reporting and communication

Part time, part time, telecommuting, the biggest obstacle is communication. No matter how hard we try, we can not achieve the efficiency and effect of centralized office communication, which is very helpless. But should do still have to do, can not do 100 points, can do 70 points is not bad ah.

Daily communication

Daily communication is in the wechat group. @others discuss problems or @me report progress, such as the completion of the document, the submission of the pull request and so on. I will also reply the results in the group @members after I review them.

If a member of the group has a separate question, it will also be discussed privately. We talked, or we called.

However, it is important to note that all chats, discussions, phone calls, etc., are a process. We document the results and record them in the task card of Teambition. That is, we do not pass the result information in the chat, the result information should have a unified record, so that it is easy to find and reply.

PS: There is also a sense of documentation that it is important for the team to have their own knowledge base.

Weekly meeting (later cancelled)

When I first started the team, there were only 3-4 people including me, and we had short weekly meetings on weekends, teleconference. But after a few meetings, it felt like there was really no need to hold weekly meetings because there wasn’t much to talk about.

If it is a company office, the leaders hold weekly meetings, which may also implement some of the company’s culture, norms and regulations, and even some chicken soup. And as an open source team, we’re not a company, so we don’t have to do all that stuff. So, after some discussion, it was decided to suspend the weekly meeting.

With so many people coming, it’s no longer feasible to hold weekly phone meetings. So, it hasn’t been driven since.

However, I think these days, such a collective meeting and communication, or to be held regularly, such as once a month. Now screen meetings are also very convenient, with Tencent meetings can easily do. We have monthly meetings to summarize our previous work, make plans for the future, and synchronize information with everyone. I’ll sort that out later.

weekly

At present, the main communication reporting mechanism is to write weekly newspaper every Sunday night.

You probably have to write a weekly newspaper every week at work. I do not know if you have considered, what is the purpose of writing a weekly newspaper? I guess some people might say: weekly newspaper, the leader to monitor everyone’s work, to see who is slacking off – in a work environment, it might be. But in our open source team, the weekly is not for overseers, because we work part-time for free, allowing for unconditional delays and systematic laziness.

In my opinion, the function of weekly newspaper in our team is to let each member summarize the work content of this week and make a plan for the next week. Make a summary and plan for your work every week, which gives your work rhythm and stages. This will make you aware of what you need to do and what you can take your time, so that you have a plan for yourself. On the contrary, if we do not have a weekly report, no summary and plan, every day in a muddle, when the monk beat the bell, the effect will be much worse.

Therefore, even if everybody goes to work, the weekly newspaper is absolutely not only used to lead the overseer. Advise everyone to treat weekly seriously, do not perfunctory, weekly is your personal improvement of a good tool.

After several adjustments, the current format of our weekly report is as follows.

  • The date range is this week
  • Work Contents of this week
  • Working Hours of the week (unit h)
  • A link to the
  • Work Plan for next week

The weekly format has also undergone some adjustments, and from that experience, I think two things are very important.

First, the number of hours you work this week. That is, each member is asked to review how much h you spent on the job this week. Also, the time needs to match the work, so don’t write about it. We have previously stipulated that if the output is below 2h every week continuously, the work will be suspended. Of course, if you are really busy, you can ask for leave in advance, and everything should be planned.

Second, related links. This week’s work content is text description, oral proof, link proof. You can link to documents, you can link to code, you have to have a work product, you have to have a deliverable. This urges you to keep a process record of all your work, and don’t be lazy when it comes to documentation, otherwise your work won’t be real.

Another thing worth noting is that people often forget to write a weekly newspaper. Then say sorry the next day and make it up. It’s human to forget something. It’s easy to understand. There are a few tricks, though, and I recommend using the Todo-list tool with time reminders. I forget things a lot, but with a tool like this, it’s a lot.

1-1 communication

1-1 communication is also a common means of team management in enterprises, that is, one-to-one chatting with team members. Since it is a 1-1 private chat, it is not as formal as a meeting chat, so you can talk about something outside of work.

I will talk to each member on the phone every 1-2 months. The time is not fixed. The usual content of the conversation is whether the feeling of the work is positive, what suggestions to the team, what jokes to make, what makes me feel uncomfortable or confused. That is, if you have a problem, you should directly raise it, and don’t keep it in your heart. For a long time, it will cause a lot of negative emotions, affecting work efficiency and enthusiasm.

About team compatibility

My views on this topic may differ from yours.

It’s not unusual to encounter a situation where, for example, a bug occurs, and it’s usually the programmer who dealt with it, or some low-level employee, who ends up taking the blame. Then blame this employee’s poor level, even the most basic XXX does not know, leading to this bug. (Of course, this may be a form of office politics. Where there are people, there are rivers and lakes.)

I have a different view on this. I remember many years ago when I took the PMP exam, I learned an unforgettable view: the leadership is 75% responsible. That is, no matter what goes wrong, the lead is 75% responsible, and the actual development team is only 25% responsible.

If the team member made a malicious mistake and wanted to delete the library and run away, that’s another matter. If he accidentally caused the problem, blame the person in charge and the team process for not thinking things through. For example, if he develops the software and goes live without testing it, it causes a bug. Then it is due to the imperfect process. How can he go live without testing it?

Back to the theme, I think a good team is compatible. It is compatible with all levels of staff, as long as the basic ability is good, positive attitude, through the team process and norms, to achieve the expected work. The value of a leader is to make the team run in an orderly and efficient manner by establishing the team’s processes and norms, and by having the means to ensure that members follow the norms. If a member follows the rules and procedures, he can achieve the goal. PS: Of course, good employees who can do more than expected work, that’s a good thing.

In the same way, a good project architecture can be decoupled from any code, so that even if the code is poorly written somewhere, it doesn’t affect the overall situation. When you want to refactor this module, you can replace the bad code once and for all.

A few days ago, a member of our team accidentally deleted the dev branch of the code, and I initially blamed him for it. It was out of passion. When the problem was solved and I calmed down, I would review the problem by myself, which is actually my responsibility, or the responsibility of our team’s R&D process. Github already supports branch protection. Therefore, I have now added dev branch protection (master branch protection already exists).

This error-tolerant team process is also improved step by step by making mistakes. But only if you consciously consider the responsibility of the person in charge and the team, rather than one member taking the blame. Otherwise, team process compatibility is not possible.

This is not to say that our team and technical architecture is great, but I will continue to do well according to my own ideas.

Research and development management

Refactoring 4.0 from the beginning until now has been mostly a research and development task. Assign a new feature, then start writing requirements, design, code, walk through, and finally merge the code and release.

Task flow

We use TeAmbition for task management, which is similar to the agile project development process.

But unfortunately, with the increase of members, Teambition has to charge, and the charge is quite expensive. I’m researching other task management systems and haven’t found one yet.

These systems in the country, they all charge. Github has its own task management, but it is weak and in the works.

However, I’m also thinking about dividing the product direction later, and I’ll try it out once V4 is released. If there are more than 10 people in one direction, it is not a very scientific way to organize.

Stage 1 – Assign tasks

Create new r&d tasks, assign responsible people, and assign start and end times. I’m the one who does all of this.

When creating a task, specify what to do in the remarks of the task, the clearer the better. This is the “dumb communication” discipline mentioned above, and I practice it myself.

The end of the mission, that’s what I evaluated. But we allow an unconditional extension, that is, when the end time is up, you can modify the end time yourself. After all, we are a part-time team, and indeed there is no way to guarantee working hours, which we can understand.

But I recently discovered a problem. People think they can get an unconditional extension, and then every time they change the end date, they don’t really think about it, they just change the end date. Wait for two days and delay, then change a. I think this is a very unplanned thing, I will try to solve it, can not let it go on

Stage 2 – Requirements and Design – Requirements first

Requirements guide design, and design guides development. This is a serial process, and if you don’t do it right, there are risks.

If it’s a new feature development that involves U, I, or a user API, you have to write a requirements document, put it in the text. After writing it, submit it to me for requirements review, and I will reply to the review suggestions. Generally, it takes 2-3 rounds of review before the requirement is approved. At this point, we have accumulated many requirements documents.

You might wonder, should programmers write requirements? Isn’t it always the PM who makes the requirements and then the programmer who develops them? My answer to this question is firm: the programmer must be actively involved in the requirements and understand them and the business as quickly as possible.

In large companies, there are many talents and clear direction division. Professional PMS write requirements and hand them over to programmers for development. However, programmers should also actively participate in the requirements review meeting to discuss, and if they have questions about requirements, they should also raise them. In a small company with a small team and fewer people, we can only make everyone undertake more requirements, that is, write requirements directly. However, this approach is also the best way to participate in requirements.

As mentioned above, technology becomes less competitive as programmers get older, so align business and technology, which means dive deep into requirements. As mentioned in The book “Talking about Architecture”, the personnel organization of modern Internet enterprises tends to be more and more versatile talents with small teams to improve efficiency.

A common problem that team members have when writing requirements is to over-reference other products and transfer all functions. So when I do a requirements review, I always cut some requirements.

Those more mature products, their functions are a lot of people spend a lot of time, and full-time working time, slowly do up. But with a product like ours that’s just starting out, it shouldn’t be that comprehensive. According to the 2/8 principle, we can first do 20% of the common functions well, to meet 80% of the user’s scenes, it is already ok. Others will be upgraded iteratively based on user feedback.

Also, write requirements with subsequent design and implementation in mind. The more complex the requirements, the more complex the design, and the more complex the code. First, it increases development time; Second, it increases the probability of subsequent bugs.

Stage 2 – Requirements and Design – Design again

Design here, in terms of technical solution design, is not UI design.

According to our development specification, all development tasks (except simple bug fixes) must be written technical solution design. Demand knows design, design guides development, no design no development. In addition, after writing, I have to submit to review, generally need to review 2-3 rounds to pass. So far we have accumulated so many technical solution documents.

Technical solution design, in plain English, is to write how you plan to develop. Because we are multi-person collaborative development, you don’t write out, directly to develop, write code to I can not understand. Therefore, design is a very necessary communication process in multiplayer development.

There is no standard format for the technical scheme design, we do not limit the format, we can refer to the existing documents to write. For example, which files do you want to create or modify? How many classes do you want to create? What is the implementation logic of the core functionality? What are the data structures generated after the implementation? Are there any technical difficulties? How are you going to do unit testing? — Wait, the key points of this feature development, no details, but comprehensive, make sense.

Some friends may think that the technical solution is a form, think that they directly develop the code on the line, writing the technical solution is a waste of time – at this time is very wrong!! We analyze it from two aspects:

  • If you really knew what you were doing and could just write code, it wouldn’t take much time for you to write a technical solution document. If you are so familiar with it, it will be finished in 1h at most. Will you be delayed for the 1h? I’ve never seen such a reason for delay.
  • But if you think you know it, but you’re having trouble writing it, ask yourself, are you really that familiar? Or do you think you’re familiar? If you can’t document it, I don’t trust you to write the code quickly. Therefore, the process of document writing is also a process of inspection. Problems are discovered and solved as early as possible, or development plans are adjusted as early as possible. When they are discovered and modified, it is too late and delayed. This is often the case, not the result of an hour spent writing a document.

Before, some new team members gave feedback that they had never written the technical plan, and they did not know how to write it. Looking at a document without writing is like going straight to code. It’s a matter of skill. This stage is about writing the design document, but it doesn’t mean you shouldn’t write code. Start coding, get some ideas, do some validation and testing, and then write the design document. Although you write code, this phase is not called development, and your output is not code, but design documentation.

In my observation, the technical solution design is not well implemented in all companies, large or small. It’s like unit testing: everyone thinks it’s a good thing, but few people actually do it. I think we should be on its understanding and application deviation, did not find its real value. But for our team, the technical solution design will continue to be implemented, and will continue to optimize.

Stage 3 – Development and self-testing

The requirements are determined, the technical solution design is approved, and then it is much easier to develop.

Self-test, the current implementation is not good, but this process is still very important, so I will continue to do it.

I think the reasons are as follows: First, the self-test is not solidified into the process; Second, too much reliance on individual initiative should be cross-tested.

Stage 4 – Submit PR, or Pull Request

According to the development specification, new Git branches are required when new features (or bugs) are developed. Once you’re done, commit the Git branch and then submit a Pull Request to be merged into dev. We do not allow direct manipulation of public branches such as dev Master.

Note that after submitting the Pull Request, the submitter is required to take a look at the Files Changed for himself, in case there are some low-level errors, so that he can find and modify them himself. There have been times when I received a Pull Request and immediately recognized the low-level error and rejected the modification, wasting my time. Everyone should be responsible for their own output, be careful and don’t submit mindlessly.

Then do a code walk based on the Pull Request. Code walk check I will do very detailed, mainly look at

  • Whether the code logic is reasonable
  • Are code comments formal and reasonable
  • Unit tests, completeness of use cases
  • Develop documentation, use documentation, is it complete
  • Global event, does it cause other interference?
  • Timer, custom events, whether there is the risk of memory leakage?

If there is a problem with the code walk, we will reply to the comment on the Pull Request and notify the developer. Based on the comments, developers continue to make changes, and then resubmit and re-code walkthroughs. Under normal circumstances, it takes 1-2 rounds to pass the review.

Stage 5 – To be released

Once the Pull Request code passes, it is merged into the dev branch. At this point, the development task is complete and the developer can move on to other tasks. But it has not been released to NPM at this time.

Phase 6 – Released

Every once in a while, the currently accumulated functionality to be released is merged from dev to Master and released to NPM. These features have been released and are complete.

Of course, if it’s an urgent bug fix, get it to NPM as soon as possible. Regular features, as planned, are released once a week.

Follow-up bug fixing process

Bug fix, small change range, and R & D task is not the same, not suitable for this task management. Bug lists are more suitable for management, while pure tables are less suitable for task tracking.

Consider using Github task management, since it works well with github issues and PR. I’ll try it out.

The knowledge base

A regular RESEARCH and development team must have its own knowledge base. We chose the language sparrow as the knowledge base, where all the documents, processes and records are recorded. When new members join, they can use these documents to quickly learn about the business and code.

However, after several months of use, I feel that these documents have become a bit chaotic. I will continue to sort them out and regroup them later.

When recruiting new members, I always emphasize that we are an amateur open source team, but the regular army is not a wandering army. We have a formal R & D process, R & D specifications and knowledge base, which are standard parts of a R & D team.

So, if you are still working in a less mature r&d team, joining us will quickly familiarize you with the management style of a regular R&D team. That’s one of the things that attracts new members.

Code architecture and technical infrastructure

As mentioned above, a good team is compatible. It doesn’t pick and choose. In the same way, good software architecture design is compatible, it doesn’t pick the code. Even if some part of the code is not written well, it does not affect the overall situation, to achieve sufficient decoupling.

In addition, technical infrastructure should be well done, such as CI/CD. This allows developers to focus on the business code instead of running around in different environments.

Finally, there are techniques to keep your code as readable and stable as possible. Examples include ESLint unit tests, etc.

Technology selection

Now everyone uses TS, it doesn’t seem a bit out anymore. Again, the strong typing provided by TS is really good for code specifications developed by multiple people. Moreover, the higher requirements for members can facilitate the selection of better members.

For rich text technology, we’ve always used the old Document. execCommand API, and there’s nothing we can do about it. We are serious open source products, and not professional technical research, so we still want to output products as soon as possible, can not always study technology. But a new technology solution, implementing execCommand on your own, will soon be under investigation, as described below.

The code structure

Code structure I specifically wrote a development document github.com/wangeditor-… , and also recorded about 1h video to introduce. The code should be fully decoupled and the modules clear.

Menus are separated from each other

All menus are under SRC/Menus /, and each menu is a separate folder that does not interfere with each other.

Furthermore, menus for different types (Button, DropList, Panel) can be inherited according to different classes.

Finally, in addition to developing your own menus, you can also extend them yourself, as documented.

Extensible Text listening events

Text stands for edit area. Each event in the edit area is a necessary means to achieve the function. For example, when a picture is clicked, the drag-and-drop function is displayed. Hence, textEventHooks, an extensible event mechanism.

// Each event hook function
type TextEventHooks = {
    changeEvents: Function[] // When the content is modified
    dropEvents: Function[]
    clickEvents: Function[]
    keyupEvents: Function[]
    tabUpEvents: Function[] // When TAB (keyCode ===) is Up
    tabDownEvents: Function[] // When the TAB key (keyCode === 9) is Down
    enterUpEvents: Function[] // Enter (keyCode === 13) up
    enterDownEvents: Function[] // Enter (keyCode === 13) down
    deleteUpEvents: Function[] // Delete key (keyCode === 8) up
    deleteDownEvents: Function[] // Delete key (keyCode === 8) down
    pasteEvents: Function[] // Paste events
    linkClickEvents: Function[] // Click the link event
    codeClickEvents: Function[] // Click the code event
    textScrollEvents: Function[] // Edit the region slide event
    toolbarClickEvents: Function[] // The menu bar is clicked
    imgClickEvents: Function[] // The image is clicked
    imgDragBarMouseDownEvents: Function[] // Drag the image to MouseDown
    tableClickEvents: Function[] // Form click
    menuClickEvents: Function[] // When each menu is clicked, this should not belong to TXT, but put it here temporarily
    dropListMenuHoverEvents: Function[] // Droplist menu hover event. Put it here for the time being
    splitLineEvents: Function[] // Click the split line
}
Copy the code

How do you use these events? Take picture menus for example. When the image menu is initialized, the following code is executed.

/** * bind event *@param Editor Instance */
function bindEvent(editor: Editor) :void {
    bindPasteImg(editor) // Paste the image
    bindDropImg(editor) // Drag and drop images to upload
    bindDragImgSize(editor) // Drag and drop the image size
    bindTooltipImg(editor) //Tooltip
}
Copy the code

Each of these bindings will use the above events. Such as the tooltip

/** * Bind the tooltip event *@param Editor Instance */
function bindTooltipEvent(editor: Editor) {
    _editor = editor

    // Click the image element is to display the tooltip
    editor.txt.eventHooks.imgClickEvents.push(showImgTooltip)

    // Hide the tooltip by clicking somewhere else, or while scrollingeditor.txt.eventHooks.clickEvents.push(hideImgTooltip) editor.txt.eventHooks.keyupEvents.push(hideImgTooltip) editor.txt.eventHooks.toolbarClickEvents.push(hideImgTooltip) editor.txt.eventHooks.menuClickEvents.push(hideImgTooltip)  editor.txt.eventHooks.textScrollEvents.push(hideImgTooltip) editor.txt.eventHooks.imgDragBarMouseDownEvents.push(hideImgTooltip)// change when hidden
    editor.txt.eventHooks.changeEvents.push(hideImgTooltip)
}
Copy the code

About controlling editor permissions

The editor should not expose all its capabilities to the menu, which would be very destructive, and should be controlled by permissions. It does make sense to me. However, how to specific landing has not yet been thought of, and the complexity is not high. This is something we’ll continue to discuss and work on.

Unit testing

Unit test is one of the most effective means to ensure the stability of software functions, so we are required to specify how to do unit test in the design of each technical scheme.

However, for uI-rich software like a rich text editor, unit testing is not easy to do, at least not very comprehensive. Our unit test coverage is now just over 60%, which is only passable.

However, it is not easy to do, but it can be done, at least I can unit test to make sure some basic functions are correct. This also greatly reduces our workload and improves our stability a bit.

Unit testing I plan to do a special project later to see how I can further refine it. This may require tweaking the code, such as separating out some of the logic for testing.

CI/CD

CI/CD is a hot topic on the front end, and it should be, because it’s useful and convenient. We use Github Actions for CI/CD, which is easy to learn and use.

An automated build

When the dev and Master branches push, an automatic build starts. NPM run lint NPM run test NPM run build to ensure code builds are problem-free.

Publish the development branch to the test machine

As mentioned above, when developing new features or modifying bugs, you need to pull a new branch named feature-xxx or fix-xxx. When the branches of these two formats are encountered, the automatic build will be triggered and the build result will be pushed to the test machine (a Tencent cloud server I bought myself). Then through http://106.55.153.217:8881/feature-xxx/examples/index.html to access, including feature – XXX can switch to other branches.

This feature is still very important. When the function you developed needs to be sent to others for testing or trial use, you can directly push the branch code and send the link to the test machine.

Automatically publish to NPM

Code merges into the Master branch and then pushes a tag to trigger a build and perform NPM publish to NPM.

Development of the document

Development documentation is available at github.com/wangeditor-… This is open for interested friends or new members to look up. PS: The content on Github is definitely public, but the documents on Wordfinch are not.

Note that it is important to look at the usage documentation before looking at the development documentation. Look at usage first, then implementation.

The development document is light, including the most critical highlights

  • Code structure. Understand the source code, understand the operation mechanism.
  • Develop specifications. If you want to contribute code, either formally as a team contributor or as a Pull Request user, you must follow this specification.

Problems encountered by the team

There are only two problems encountered by teams with part-time jobs and telecommuting: communication + schedule assurance.

We cannot communicate face to face like in the office environment. We can only communicate through wechat chat, phone calls and documents. Because our current RESEARCH and development process is relatively standardized, step by step, each step has documents, audit, audit is also considered as communication. Therefore, the problem of communication is not so big at present. Although the efficiency is not that high, it is still in progress with a rhythm.

Schedule guarantee this is a bit difficult, part-time work, no compulsory overtime, all on their own initiative. Therefore, in this respect, we simply let go and allow planned extension without deadline. Of course, if a task continues to fail, I’ll follow up individually and ask if there are any problems.

Generally speaking, I am quite satisfied with the actual performance of the two problems mentioned above. It is also a realistic situation, and it is quite good to be able to do so.

Future plans

Strive to be the best open source editor in China within one year. Dare not say can do Tencent document/graphite document so professional complex level, but also at least to meet the needs of other scenes.

As the number of team members increases, different directions need to be divided. The current directions of the plan are:

Editor maintenance and upgrade

The first is, of course, fixing bugs. Bugs are not terrible, because there are only two kinds of software in the world: software that nobody uses, and software that is full of bugs — as long as someone uses it, there will be bugs. The problem is how to collect bugs (such as QQ group and Github issues), identify the priority, and how to arrange bug modification efficiently and stably, and monitor the progress.

The second is to continue to develop new features. Note that new features should be developed based on user feedback, not on what you think is important.

The third is to continue to ensure the standard and quality of the code, ensure the efficiency and stability of the process, ensure the orderly and tidy knowledge base. For example, as new features are added and more modules are added, should you consider unpacking and recording asynchronously on demand?

All of these things, going from 1 to 2, are much more complicated and challenging than going from 0 to 1. But I’m looking forward to it.

“Islands”

I don’t know if that’s the right word, but I made it up myself. What the technical term is (or if there is one) I don’t know yet.

What we often call a rich text editor is actually editing text, images and so on. But today’s editors are more than just graphics. You can insert tables, code blocks, mind maps, attachments, and edit with rich text.

Therefore, in addition to images and texts, we also need “islands” where tables, code blocks, mind maps and so on are stored. Each island has its own complex operations that have no effect on the external graphics, just like an iframe. In this way, the coupling can be fully decoupled and the software design principle can be met.

In the future, special personnel will be arranged to conduct research on this direction. It looks hard, but that’s okay. Let’s do it slowly.

Since the inquiry document. ExecCommand

As mentioned above, we are still using the old Document. execCommand API, but self-development is imperative and will be arranged in a superior way.

Self-developed Document. execCommand, from a user perspective, should ideally be consistent with the native API so you don’t have to change too much code when you apply it.

Do online office

We’re not doing this to compete with professional online Office systems, and we’re not in a position to compete with them yet.

To do this, the first is to use the editor for yourself to experience what is good and what is not. And, more importantly, we’ll explore solutions around rich text editors, such as multi-user collaborative editing. That is, I think we will produce not just a rich text editor tool, but a set of features and solutions related to rich text.

The solution is commercially available.

conclusion

People might think I’m recruiting free labor to work for myself — which is totally wrong!

  • We’re an open source project. We’re not profitable. We all work for free. If you have to recruit free labor, I put myself in it first.
  • The members who join the team will get their own growth and benefits. As the head of the team, I also got my own growth through managing the team. We make progress together. We all benefit.
  • People are free to join or leave. People will vote with their feet if they are of value to themselves. We don’t have any compulsion and we can’t enforce it.

Finally, thanks again to all the team members!

By the way, keep recruiting new members and welcome PM UI QA characters as well.