Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Recommenders/Attic/ContributorsWanted"

m (→‎Potential Contributor Topics)
m (→‎Contributing)
Line 2: Line 2:
  
 
= Contributing =
 
= Contributing =
−
There is a Contributors Guide to Eclipse that may give you first ideas how you can contribute to Eclipse. Please check out [[How to contribute]] for a general introduction and than continue below with the project-specific information.
 
  
−
 
+
See [[Recommenders/Contributor Guide]] for details.
−
== Contributing Code ==
+
−
Whether you're wanting to fix a typo in javadoc or to implement the next whiz bang feature you'll need to know a few things before you contribute code. The basic life-cycle for contributing code is:
+
−
 
+
−
# Check out the sources.
+
−
# Make your changes.
+
−
# Create or update the tests to cover your changes.
+
−
# Create a patch.
+
−
# Submit the patch to Bugzilla.
+
−
 
+
−
There might be some small differences between projects and tasks, but's thats the way it works in general. If you feel uncertain, feel free to send a mail to the [http://eclipse.org/forums/index.php?t=thread&frm_id=211 forum] or [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list] at any time. Some more details on each of these steps:
+
−
 
+
−
=== Checking out the Sources ===
+
−
Code Recommenders has several GIT repositories containing the sources of the project. You need to check out the project homepage to learn about the exact location.
+
−
 
+
−
=== Building from Sources ===
+
−
Recommenders uses Tycho to build the plug-ins from scratch. Look out for the pom.xml files in the repositories. The typical command to build Code Recommenders from scratch is to enter ''mvn clean install''. That's it.
+
−
 
+
−
If this fails on your machine send a mail to the developer mailing list and report this issue.
+
−
 
+
−
=== Creating a Patch===
+
−
Creating and contributing a patch is no sorcery. With GIT creating a patch is just a one-line no-brainer like ''git format-patch origin''. Then all needed to do is to create a bug report in the [https://bugs.eclipse.org/bugs/ Eclipse Bugzilla] on the Recommenders product and appropriate component and attach this patch with a brief description what's in. No worries, if you don't find the right component at first... maybe it's a good solution to send a mail to the forum or mailing list before announcing your patch and ask where to put it.
+
−
 
+
−
Note, there is no need to send the patch directly to the mailing list unless being asked for. Contributions of this kind always have to be submitted using Bugzilla to guarantee IP Cleanliness. You may check out the [http://www.eclipse.org/legal/committerguidelines.php committer guidelines] which may also explain how and why it works like it works.
+
−
 
+
−
=== Unit Testing===
+
−
Testing is imperative to the health of the project.  Each (sub-) project has a significant amount of tests (hopefully).  If you are contributing a fix or writing an enhancement, it is a requirement that tests are written.  If you don't write them a committer will have to and that could slow down the contribution process. 
+
−
 
+
−
And: If you want to make a good impression, write tests.  This goes for any project, of course. :)
+
−
 
+
−
=== Coding Conventions ===
+
−
As with all projects, there are common coding conventions you should take care of those of the Eclipse Platform's [http://dev.eclipse.org/conventions.html Standards, Conventions and Guidelines] and [http://wiki.eclipse.org/Recommenders/CodingConventions Code Recommenders] guidelines. If you find them too  vague, ask for clarification and hints at the developer's mailing list.
+
−
 
+
−
=== Before You Create the Patch ===
+
−
 
+
−
* Commit comments are required for all code commits. Bugs should be logged to track work and the bug number and a description is then used in the commit comment to describe the change. For example when fixing a bug, use exactly: "Fixed bug xxx: <title of bug>".  The "bug xxxx" part is really important as this is what is used to relate the bugs to the build submissions, so it must be formatted exactly that way (uppercase or lowercase bug should work). 
+
−
* Before sending a patch, catch up to all changes made by others, and then run the tests.
+
−
* Don't create patches if this will cause compile errors for others.
+
−
* Ensure that every new file added by you has an appropriate license header!
+
−
 
+
−
 
+
−
=== Size of the Patch ===
+
−
 
+
−
Contributing is straight forward. Check out, change, test, patch, submit. One interesting question is about how large a contribution should be. The answer is simple. Whatever size you like but small ones are preferred - for a simple reason: All patches below 200 lines are reviewed b committers and can be included into HEAD without further IP checks. Patches that exceed 200 lines have to be reviewed by the Eclipse IP Team which may take some time. Thus, send your small patches often (say, up to one or two times a week?).
+
  
 
= Potential Contributor Topics =
 
= Potential Contributor Topics =

Revision as of 06:54, 28 May 2011

Leveraging collective intelligence for software development (as described here) has huge potential to revolutionize the way how we interact and work with our IDEs today. Furthermore, leveraging the wisdom of the software engineering crowds can happen in many different ways. Hence, Code Recommenders is seeking for contributors in many different areas ranging from test engineers to Plug-in developers, JDT experts, up to usability experts providing feedback about issues that kill the code recommenders experience. Below you find a short description of contributions we highly appreciate.

Contributing

See Recommenders/Contributor Guide for details.

Potential Contributor Topics

We maintain a list of topics we seek support for and to track who is working on them. Please check out the Recommenders/ContributorTopics for a list of potential topics/areas. If you have any questions about any of the ideas presented there do not hesitate to ask for details in the forum. We'll update the description and provide more details.

Contributor 'Types' Needed

JDT Experts

Code Recommenders seamlessly integrates with Eclipse JDT by extending code completion, performing AST code analyses, using Java Search and many other functionalities provided by the JDT. However, sometimes we have to dig deeply into the internals of JDT to achieve our goals - and sometimes it's not clear whether our solutions are best in terms of simpleness and performance. Thus, to improve Code Recommenders in terms of performance and functionality we are seeking JDT experts - or those that want to become JDT experts - to improve its integration into the JDT.

Static Analysis Experts

This topic is probably the one with the smallest target audience :-) For our code analysis we use the IBM WALA byte code toolkit which is an excellent toolkit for analyzing code. It comes with a interprocedural control-flow graphs, abstract interpretation capabilities, fix point iteration etc. Code Recommenders aims to continuously improve its analysis in terms of precision and (especially) performance. If you are familiar with WALA - or want to learn about it - we welcome your contributions!

Plug-in Developers

Aside code completion, Code Recommenders offers many more tools like example code search engine, smart bug/API misuse detection, extended javadoc, collaborative template stores any many things more. Checkout Recommenders/Proposal for a summary of the planned tools. All these tools are based on Eclipse RCP, i.e., they build on well-known concepts like views, editors, workbench listeners etc., meaning that supporting Code Recommenders does not necessarily require you to have a background on machine learning or static analysis. If you are familiar with Eclipse Plug-in development you can take responsibility on tasks like user customization etc. or even may take the lead on various components like the crowd-sourced usage data collector or any other tool we work on at Code Recommenders. There is a plenty of opportunities. Interested? Then join us on the forum and dev mailing list and let us know what interests you.

Test Engineers

Code Recommenders aims to continuously deliver its software. This requires a high quality test suite. However, building great test suites needs excellent test engineers! If you are an experienced test engineer, and would like to support us in creating a continuous delivery platform for Code Recommenders contact us on the dev mailing list. We are currently building on Hudson and start out building automated test suites for Eclipse RCP plug-ins and analysis engines as well.

Usability Experts

Actually, every user is a usability expert in its own right but only few of us take the time to provide usability feedbacks and to tell the development team what kills the user experience. Thus, Code Recommenders seeks users that aim to provide usability feedback and unsparing critiques of the tools. Without this feedback the development teams wastes time and efforts in directions that may turn out as complete mistakes in development. The earlier the team gets feedback and help in prioritizing things the better and faster Code Recommenders can grow. Thus, we need your support. A perfect forum for these kinds of contributions is the forum.

Documentation Writers

Granted, it looks like an escape when a development team is searching for documentation writers. However, one of the hardest challenges in writing documentation is matching your audience. Technical writers are trained for this and thus we would greatly appreciate your help on user and developer documentation. If you think documentation is unclear and needs refinement, please point out this issue and report them to the forum. Also, user and developer documentation is hosted in this wiki which allows to improve it quite easily. We encourage you to jump in and improve code recommenders' documentation.

Own Ideas?

The development team is open for any new ideas and suggestions how Code Recommenders may improve Eclipse IDE. Thus, if you like to share your thoughts or even want to contribute your own extensions to Code Recommenders simply contact us on the forum.

Something Left Over?

This list is neither exhaustive nor has any particular order. If anything is left open, contact us on the forum.

Retrieved from "https://wiki.eclipse.org/index.php?title=Recommenders/Attic/ContributorsWanted&oldid=252708"

Back to the top