redView

riena emf dynamic views

Contribute

redView Community

You can help us to build the redView Community.

There are many ways how to contribute to redView:

  • Sourcecode
  • Documentation
  • Test
  • Report Issues
  • Donate

Contact: send an email to developer at red-open.org.

Sourcecode

You’re using redView and have some cool ideas how to extend the features. Write the code and attach the new code or patches to an Issue from our Bug Issue Tracking System. After some time you can get write access to our Mercurial Sourcecode Repository.

redView Source Repositories are available from different places:

SourceForge: https://sourceforge.net/projects/redview/

bitbucket: http://bitbucket.org/ekkescorner/redview

eclipseLabs (Google Code): http://code.google.com/a/eclipselabs.org/p/redview/

You can choose what you like or where you already have accounts. All repository always have the same changesets pushed to.

If you committ changes, here are some rules of granularity:

based on discussion from egit-dev mailing list
(https://dev.eclipse.org/mailman/listinfo/egit-dev)

  • Make small commits, as small as reasonable. This makes them easy to review
  • Each commit should have a commit message that explains very clearly what the commit sets out to achieve (unless this is abundantly clear from the code itself, which is basically only the case for trivial patches). Also, when you fix a bug then report which bug you fix. When there are deeper reasons for doing things the way the commit does, then explain these as well. This all is for the reviewers and yourself: the context of the commit is completely clear.
  • Do not mix concerns in commits: have a commit do a single thing. This makes them reviewable “in isolation”. The purpose of the commit is clear and can be understood easily by the reviewers and yourself.
  • Do not break the build and tests for _any_ commit: this is very important for bug hunting.
  • Split your work into multiple smaller pieces of work (when possible) and implement each of these pieces in a series of commits.
  • A series of commits should work towards a ‘feature’ in a clear way and only ‘enable’ the feature in the last commit of the series.
  • In a series of commits first lay the groundwork and then build on that towards the feature.
  • Do not mix concerns in branches: when you encounter a bug while working on something then create a new branch to fix the bug. If your work depends on the bug being fixed then rebase your work on that new branch

Documentation

You miss some documentation ? Help us and write missing parts or correct the existing.

Test

We know – there are many tests missing yet – help us writing Tests to make the software better.

Report Bugs

And as always: if you notice a problem please add an Issue to our Issue Tracking System.

Donate

Most development of redView was done in the free time of open source developers – you can help and donate if you like it.
Support This Project

Advertisements
%d bloggers like this: