Skip to content

Latest commit

 

History

History
102 lines (75 loc) · 5.78 KB

CONTRIBUTING.md

File metadata and controls

102 lines (75 loc) · 5.78 KB

#Lucene.NET Contributor's Guide Hello new contributors, thanks for getting on board!

Before anything else, please read The Getting Involved article at apache.org. In particular, we will need you to have an ICLA with Apache and to feel comfortable with Git and GitHub.

Start by forking Lucene.NET on GitHub. For every contribution you are about to make, you should create a branch (tracking master!) with some descriptive name, and send us a Pull Request once it is ready to be reviewed and merged.

And please git rebase when pulling from origin/master instead of merging :) More information can be found over at Atlassian.

##If You are Willing to Help with Porting Code

  • Please make sure nobody else is working on porting it already. We would like to avoid doing redundant work. We ask that you communicate clearly in this list that you are going to work on some part of the project. A PMC member will then either approve or alert you someone else is working on that part already.

  • Use automated tools to do the basic porting work, and then start a manual clean-up process. For automatic conversion we are using Tangible's Java to C# Converter. We have licenses to give to committers) and it proved to work quite nicely, but I also hear good things on Sharpen. Check it out here and pick the tool you are more comfortable with.

  • Conventions & standards: not too picky at this point, but we should definitely align with the common conventions in .NET: PascalCase and not camelCase for method names, properties instead of getters/setters of fields etc. I'm not going to list all the differences now but we probably want to have such a document up in the future. For reference have a look at Lucene.Net.Core, while not perfect it is starting to shape up the way we want it.

  • In general, prefer .NETified code over code resembling Java. Enumerators over Iterators, yields when possible, Linq, BCL data structures and so on. We are targeting .NET 4.5.1, use this fact. Sometimes you will have to resort to Java-like code to ensure compatibility; it's ok. We would rather ship fast and then iterate on improving later.

  • While porting tests, we don't care about all those conventions and .NETification. Porting tests should be reduced to a copy-paste procedure with minimal cleaning up procedure. We are working on tools and code helpers to help with that, see for examples see our Java style methods to avoid many search-replace in porting tests, and a R# plugin that will help making some stuff auto-port when pasting.

###Code that is currently pending being ported from scratch (+ tests) == up for grabs:

Also, some analysis modules:

###Code that is ported and now pending manual cleanup, and then once its compiling porting of its tests == up for grabs:

The rest is pretty much under control already.

##If you are more into Fixing Existing Tests

##Other types of help

We will definitely need more help (like normalizing tabs/spaces, license headers, automating stuff, etc) but we are not there yet!

##Thank You!

Again, thank you very much for your contribution. May the fork be with you!