How to do an open source project (a)

In fact, a good open source project is a relatively time-consuming job to worry about, it's the most difficult in addition to code maintenance, also includes maintenance and continuous follow-up of late. I have done a lot of open source projects, but stick with it, there are confident that we can continue to maintain only Magicodes.IE. Allow me here to be a wave of hard-wide:

Magicodes.IE

Import and export common library that supports Dto import and export as well as dynamic export, support for Excel, Word, Pdf, Csv and Html. NCC has joined the open-source organization.

• Github：https://github.com/dotnetcore/Magicodes.IE
• Cloud code (manual synchronization, no maintenance): https://gitee.com/magicodes/Magicodes.IE

How to build a good open source project?

We return to the topic. How to make it an open source project? Next for the Road, said:

1) have a good idea and creativity

If you are doing repetitive things, but there is no right wheels of time, then we can create a.

If the wheel a lot, but not easy to use, or not general enough, then we can begin to write one.

Magicodes.IE is in this case was born. Import and export is a very common scenario, there are many related components, such as Take export Excel, the mainstream there EPPlus, NPOI library and so on. So why do we need to re-wheels? Because we found that the use of these libraries in most scenes we all need to do some repetitive coding and coding specific to Excel operations to meet our needs, then there is no more appropriate approach? So there Magicodes.IE, by setting Dto will be able to meet most of the scenes of importing and exporting, and also support other formats in addition to the import and export of Excel.

2) Code written

Code standards, easy to read these are essential. Especially in the case of more than remote collaboration, code review, on a regular basis reconstruction is also very necessary. Otherwise you even want to contribute, but also able to understand not?

3) adequate testing

Code written, obviously digging up is dry. With the longer the project, code refactoring or the greater the need to protect the iterative function test, not personal feeling or you can compile.

So how do adequate testing it?

1. Complete unit test

   Each iteration or function Bug fixes, are to improve good unit tests. Unit testing is the basic guarantee of the reliability of the code.

   

2. Improve code coverage as possible

   Code coverage as a guide and an indicator to some extent can complete extent of reaction test, it is a means of software quality metrics. 100% code coverage does not mean 100 percent bug-free application, code coverage as a quality target does not make sense, and we should use it as a means of testing is not covered by the code of discovery.

   By code coverage testing, we can understand the testing process and local coverage not covered, the risk may exist. Not covered by the code analysis, reverse thrust in the adequacy test design, test design stage to further clarify the issue.

   Code coverage test will also help us find dead, redundant code, history, dead code, to facilitate reconstruction.

   

3. Use automated testing to guarantee each submission and verification PR

   There are many open source projects DevOps services to choose from, we can build on its own automated tests to ensure the quality of open source projects to be submitted for each, PR verify, and as a reference resource release.

   

4) friendly document

Documentation has been a problem open source project works:

• Huan write the code, documentation dystocia.
• Localized documentation (Chinese document) no problem, other language document (document in English) is difficult to write.
• Always keep up with updated documentation updated version of the iteration code.

Friendly document has been open source projects to attract users to the primary standard, so the document is a must.

Magicodes.IE document also actively supplement and improve, a lot of hope that we can support.

 

5) release planning and management

For open source projects, the planning version and release version should not be a casual thing. After all, the wrong version may give users a catastrophic problem. Unreasonable plan, the project will also be brought into the ditch.

Here to share a few experiences:

• We plan to release plan by collecting feedback. As Magicodes.IE to collect user feedback through Issue, to discuss the launch of the new version:

• Resources issued Edition provides a detailed log version, for users reference and tracking:

  

• Beta Beta pre-release version of the package, such as the image above 2.2.0-beta2.

6) do a good job promotion

In fact, that is, he may be required to make, really need him know of his existence. From a technical person's point of view the following recommendations:

• And technical communities, sharing dry, no water base, not Xialiao
• Join well-known open source organizations such as NCC Magicodes.IE joined the open-source organization
• Do not bother sprayer. Dry valuable thing they think, do not ignore those Muggles only spray but what it will not do. For the author of open source greatest damage is actually sprayer nozzles and guns, we are using the spare energy to support and pay, contribute to the community, do not plan to support you, but you do not want to momentary loose tongue! Not like to use that you roll ah, not with that you write a better use of the sharing out ah!

7) attention to feedback, continuously updated

• From the Issue, to the tag.

  When open source project reaches a certain size, the community will give a lot of feedback. This is certainly not suitable for individual combat, then timely form their own team of open source or open source Management Committee is very necessary. At the same time, many problems are often community feedback is too far to the specific business needs, then we need to extract the common needs.

  

• Welcome to PR, the timely processing of PR!

  In the early open source projects are often only use energy amateur operation, then each PR is invaluable, the team must be timely verification and processing. First priority to function, then the appropriate reconstruction.

  

• Size version of the plan in advance, small fast iterative version!

Open source project requires both long-term planning to ensure the long-term direction, also we need to have short-term plans and goals. So the team is helpful to users. At the same time small version planning or considering functions can also be explored by way of Issue and users:

At last

Benpian only the author of the first article Magicodes.IE explain how to do an open source project, then, we will explain how to complete the badge, DevOps based on open source projects, and so on.