View source for Committer Contributor Hangouts/august 22

==Time==
10:30hr EST

== Presentation ==

Richard Burcher from the Eclipse Foundation will talking about Changes your project may have to make to keep developing when it comes to the Eclipse Foundation as a project.

== Hangout Link ==

Watch [https://plus.google.com/events/cv5kt1jlqs3fg0kgkig60k80brc Event].

== Participating in Q/A ==

* Email questions to emo@eclipse.org.
* Ask questions inside Hangout using chat function.

== Hangout Video ==
 
* Video will be uploaded to the Eclipse YouTube channel after the Hangout [https://www.youtube.com/user/EclipseFdn here].

== Discussion Script ==

=== Changes your project may have to make to keep coding when it comes to the Eclipse Foundation as a project ===

==== speaker introduction ====

Richard Burcher is the Community Manager at the Eclipse Foundation

=== structure of talk ===

==== summary ====

new projects coming to the Eclipse Foundation may have to make a few adjustments to how they develop and release code. for the most part, they're pretty easy adjustments to implement and in many cases you may be following some or all of them already:)

one item that bears discuss that influences many of the technical decisions here at the Foundation is, freedom of action. we need to ensure that anything we provide to folks via an external service (ie GitHub) will not affect a project if that service was to no longer be available or change its business model. we need to ensure we have all the information mirrored and/or hosted on our infrastructure.

at the end of the day, there's a lot here to know and understand. we acknowledge that and we're here to help you in any way we can. get in touch with us (EMO) at [mailto:**emo@eclipse.org** **emo@eclipse.org**].

==== discussion ====

===== basics =====

broken this down by major development theme

* repositories<br />
** Git<br />
*** you'll need to be using Git. lol just had to make that explicit.<br />
** GitHub<br />
*** we support that too:)<br />
*** if you're using GitHub currently, you'll need to transfer your code repository over to us.<br />
*** you're project will be hosted on one of our GitHub organizations.<br />
* bug/issues tracker<br />
** we're Bugzilla based.<br />
*** if you're using something other than Bugzilla, you'll need to switch and use our Bugzilla instances. it's up to you how you want to deal with the project bugs on the other tracker. we just ask that ongoing work happens in our Bugzilla instances.<br />
*** we don't currently support GitHub issues yet. we know folks want this and we are working on a solution.<br />
* communicating with your community<br />
** we're mailing list and forums oriented.<br />
*** you'll need to ask your community to use the mailing list(s) we create for your project.<br />
*** you'll need to ask your community to subscribe to the new mailing list(s). we don't auto-subscribe folks.<br />
* build infrastructure<br />
** we use Hudson for continuous integration.<br />
* developers<br />
** we categorize developers into two distinct categories:<br />
*** committers
**** agree to abide by our Committer [https://www.eclipse.org/legal/committerguidelines.php Due Diligence Guidelines].<br />
**** they're elected to a specific project.<br />
**** have full access to commit bits to projects repositories.<br />
**** have access to Eclipse Foundation resources (project website, download servers, build infrastructure).<br />
*** contributors
**** folks who contribute code to a project. think pull-requests.<br />
**** do not have commit access to a projects repositories.<br />
**** need to have agreed to our [https://www.eclipse.org/legal/CLA.php Committer License Agreement (CLA)].<br />
**** contributors can become committers.<br />
** general notes about access<br />
*** everybody (with an [https://dev.eclipse.org/site_login/createaccount.php Eclipse account]) has read access to everything, with the exception of the [https://wiki.eclipse.org/IT_Infrastructure_Doc#Builds build server] and [https://wiki.eclipse.org/IPzilla IPZilla].<br />
* administrative<br />
** projects will need to be familiar and follow our processes/policies.
*** [https://www.eclipse.org/projects/dev_process/development_process.php Eclipse Development Process (EDP)]<br />
**** think of this as our overall guidelines for projects at the Foundation.<br />
*** [https://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf IP Due Diligence].
**** this defines how code contributions are handled, how code is tracked, how 3rd party libraries are handled, legal reviews, distribution of code/binaries etc.<br />
*** [https://wiki.eclipse.org/Development_Resources/Contribution_Questionnaire Contribution Questionnaires (CQ's)]<br />
**** these are the mechanism for managing/tracking the intellectual property that goes into your project.<br />
**** they are the interface between your projects code and the Eclipse Foundation IP Team.<br />
**** you'll be submitting these tickets for your projects initial code contribution, requests to use 3rd party libraries and for significant code contributions from contributors.<br />
*** [https://wiki.eclipse.org/Development_Resources/HOWTO/Release_Cycle Release Reviews]<br />
**** this is how you make your project available to consumers for download.<br />
**** required because:<br />
***** they summarize what the project has added/fixed/removed for this release.<br />
***** verify that the IP Policy has been followed and all approvals have been received.<br />
***** verify that the project is continuing to operate according to the Principles and Purposes of the Eclipse Foundation.<br />
***** only needed for major or minor changes to code base. bug fixes (service releases) do not require a review.<br />
***** there are two scheduled release slots per month.<br />
**** we are very flexible and quite accommodating:)