Date: Thu, 28 Mar 2024 19:36:44 -0400 (EDT)
Message-ID: <1472041112.29210.1711669004858@lyrasis1-roc-mp1>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_29209_238084889.1711669004858"
------=_Part_29209_238084889.1711669004858
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
Welcome, New Com=
mitters!
To get started:
- Send the following information to cwilper (at) duraspace.org:=20
- Your duraspace.org userid. This is used to grant you committer-level pe=
rmission on the resources hosted on the website (JIRA, Confluence, Bamboo, =
etc)
- Your sourceforge.net userid (If you don't have one, create one here). We use sourceforge.net to distribute releases, so=
we need your userid there in order to grant you write access.
- Your GitHub userid (If you don't already have one, sign up here. GitHub=
hosts our source code repositories for the project; we'll need your id to =
grant you write access.
- If you're a Skype user, your Skype userid. If you don't use Skype=
, please provide a phone # and/or Instant Messaging info.
- Sign up to the Fedor=
a Development list.
- Sign up to the Fedora=
Codewatch list using your userid@sourceforge.net address. This is a public list that all committers subscribe to. It=
's used solely for automatic notification of Subversion commits and automat=
ed test results. It is necessary to sign up using your sourceforge.ne=
t id; commit notification will not work otherwise. Make sure you have=
set up your Sourceforge account so that emails to userid@sourceforge.net a=
re forwarded to your usual address.
How We Keep In Touch
The team keeps in touch on a day-to-day basis via the development list a=
nd Skype. We generally try to keep significant discussions on the list, but=
prefer Skype for higher-bandwidth discussions.
We also have weekly, virtual Fedora Developer Meetings where we discuss our recent work o=
n the FCRepo project. This also gives us a way to share what we're doing wi=
th interested members of the community.
What To Work On
While we collectively prefer the high-priority tracker items (as determi=
ned by the user community and committers) to be worked on first, all contri=
butions are appreciated. You may work on any unclaimed items that exist in =
the FCREPO tracker in JIRA.
If you want to work on a new feature that isn't in the FCREPO tracker ye=
t, please feel free to submit it, and open it if it's an obvious bug or imp=
rovement that needs work. If not, leave it in the "Received" state =E2=80=
=93 this will trigger a discussion of the issue in an upcoming Fedora Developer Meeting.
Claiming an Issue
Once you have an issue to work on, simply assign yourself as the owner i=
n JIRA. This lets everyone know that you plan to begin working on the issue=
soon. If you find that you cannot complete an issue, you should 1) r=
emove yourself as the owner to give other developers an opportunity to work=
on it and 2) if you've created a branch for it, remove the branch.
Coding Guidelines
- Code Style
The project's coding style is currently best described by the Eclipse sett=
ings in src/build. Here are the major rules:=20
- Four space indents for Java, and 2-space indents for XML. NO TABS.
K&R style braces:
if (cod=
e) {
// code
} else {
// code
}
- Dont use wildcard imports
- Write Javadocs for public methods and classes. Keep it short and =
to the point.
- Avoid public instance variables; use accessors.
- Use public methods sparingly; implementation details are not public.
- Logging
We currently use SLF4J for logging. When writing log messages (especially =
INFO, FATAL, and WARN), consider your audience. Don't over-use INFO; =
these messages are always logged by default.
- Testing
Use JUnit for unit, integration, and system tests. When making chang=
es, please take the time to write tests as needed. We are not looking=
for 100% coverage here, but the developers will have a lot more confidence=
in your code if you can show that it works. See the readme.txt in th=
e root of the source tree as a jumping-off point for adding your tests to o=
ne of the suites. Here's a brief description of the basic types of te=
sts we run:=20
- Unit - Tests a single class. These tests are typ=
ically very quick to run, and therefore get the most use by developers.&nbs=
p; Unit tests don't touch the disk or interface with classes other than moc=
ks. If you can cover a scenario adequately in a unit test, you should=
prefer implementing it as such (and not as an integration or system test)<=
/li>
- Integration - Tests multiple classes working together.=
May touch disk or interact with a "test" database.
- System - Works against a running Fedora server in a gi=
ven configuration. These are "block box" style tests against the publ=
ic APIs of Fedora. These take much longer to run than unit or integra=
tion tests because they require significant setup.
Using Git
Please see Git Guidelines and Best Practices
Closing an Issue
Once the relevant code has been committed and passes the automated tests=
, you can resolve the issue in JIRA. Prior to resolving an issue, dou=
ble check to make sure the metadata is accurate in the tracker.
How we do Releases
See the Fedora Releas=
e Process document.
If you find a need for licensed software to do your Fedora development (=
e.g. an IDE, Java profiler, other tool), contact DuraSpace (email: sysadmin=
at duraspace.org) and we can try to obtain a license. Many non-free, licen=
sed development tools offer free "open source" licenses. Some tools t=
hat DuraSpace has already obtained committer licenses for include: IntelliJ=
IDEA and YourKit Java profiler.
------=_Part_29209_238084889.1711669004858--