https://wiki.jenkins-ci.org/display/JENKINS/Governance+Document
I'd like to get this officially blessed in the future project meeting
--- I think it'd be a great accomplishment for Jenkins User Conference.
I'd appreciate any feedbacks and things that it needs to cover.
[1]
http://meetings.jenkins-ci.org/jenkins/2011/jenkins.2011-08-31-18.00.html
--
Kohsuke Kawaguchi http://kohsuke.org/
There's only one point where I have a slightly different opinion:
https://wiki.jenkins-ci.org/display/JENKINS/Governance+Document#GovernanceDocument-Plugins
"Since much of such local culture is implicit, new contributor shouldn’t worry too much about offending the culture by committing code. You can either try to contact existing developers upfront, or make a commit and accept the chance that they might revert that."
I think that the modus operandi should always be to ask the existing developers upfront before doing any commit. If there's no timely response (1 week or so), feel free to commit.
Another more open and still acceptable (to me) option would be to commit away, but at least inform the committers about it.
cheers
Kutzi
-------- Original-Nachricht --------
> Datum: Wed, 7 Sep 2011 09:28:14 +0200
> Von: nicolas de loof <nicolas...@gmail.com>
> An: jenkin...@googlegroups.com
> Betreff: Re: RFC: making our mode of operation more explicit
> Looks good to me,
> I've just added a link to bi-weekly meeting minutes archives
>
> 2011/9/6 Kohsuke Kawaguchi <k...@kohsuke.org>
>
> >
> > The AI I got in the last project meeting [1], of writing our implicit
> mode
> > of operations into something more explicit, is growing into the
> following
> > document:
> >
> >
> https://wiki.jenkins-ci.org/**display/JENKINS/Governance+**Document<https://wiki.jenkins-ci.org/display/JENKINS/Governance+Document>
> >
> > I'd like to get this officially blessed in the future project meeting
> --- I
> > think it'd be a great accomplishment for Jenkins User Conference.
> >
> > I'd appreciate any feedbacks and things that it needs to cover.
> >
> >
> > [1] http://meetings.jenkins-ci.**org/jenkins/2011/jenkins.2011-**
> >
> 08-31-18.00.html<http://meetings.jenkins-ci.org/jenkins/2011/jenkins.2011-08-31-18.00.html>
Nice doc and IMHO very usefull for newcomers.
Currently I have no idea how to improve it (what else shoudl be covered), i.e.
I like it as it is
If you have trouble figuring out who to contact, the good fallback
option is the dev list.
--------------
--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Nectar, our professional version of Jenkins
On 09/10/2011 02:57 AM, Jerome Lacoste wrote:
> I've made a few small changes
> (https://wiki.jenkins-ci.org/pages/diffpages.action?pageId=58001392&originalId=58001788
> <https://wiki.jenkins-ci.org/pages/diffpages.action?pageId=58001392&originalId=58001788>)
>
> Some comments:
>
> ==== Document structure:
>
> The "Project structure" section lists mostly roles and also references
> things defined later (in "how we develop code"), e.g. core, plugins.
> Because of the that maybe we should move the Code structure up. Also
> this section could be renamed as "Project roles" or "Project stakeholders".
Done. I believe I copied the section title from Apache document.
> In the document, we may also want to add some info about
> * third party libraries (used in core or outside, e.g. in backend)
> * patching third party libraries?
Added sections under the license.
> * infrastructure: plugin update center, git[hub], wiki, jenkins on
> jenkins, backend, etc
I've added those as well in the infra section. But now that I added it,
it might be better split off and maintained by the infra folks.
> * maybe something about how jenkins itself is reused (for automation). I
> think "eating your own dog food" is not necessarily a goal but when it
> fits the pragmatic aspects, it's generally favored.
Added "automation" under philosophy
> The overall toc would look like:
>
>> who we are
>> Philosophy
>> License
>> Code Structure (MOVED UP) (core, plugins, third party)
>> Project Infrastructure (NEW)
>> Project roles / Actors / Stakeholders
>> Communication
>> How we develop code (same as before but for core/plugins moved up)
>> How to join the project
>
> If you think this is meaningfull, I can change the document.
I'm not sure if I understand the "code structure" part and "how we
develop code" part. I believe you are suggesting we move some h3
subsections from "how we develop code" into new h2 section "code
structure", but not sure which subsections you intended to move.
> ==== Nitpicks
>
> == License
>
> "The core is entirely in the MIT license, so are the most infrastructure
> code (that runs the project itself), and many plugins. We encourage
> hosted plugins to use the same MIT license, to simplify the story for
> users, but plugins are free to choose their own licenses, so long as
> it’s OSI-approved open-source license."
>
> shouldn't there be something like "... and compatible with the core,
> i.e. don't prevent things allowed by the core license".
>
> IANAL.
I think plugins are allowed to restrict certain rights on themselves
that core would allow to core. For example, when you develop an ASL
licensed plugin, you are making users agree that any patch submitted
would be also under ASL unless explicitly said otherwise. Core being MIT
doesn't say that.
MIT being more liberal, if we require that plugins grant all the rights
that core grant for itself, then we'd be effectively forcing all to be MIT.
Perhaps you mean "plugins shouldn't impose any additional restrictions
on the core", but that is actually one of the freedom allowed by MIT (to
combine it with some non-free code), so I don't think we want to say
that either.
> == lower barrier of entry
>
> " is partly achieved by structuring the project to core, plugins,
> modules, and other independent pieces,"
>
> * add links to the subsections defining those things, or maybe add a
> single link to the "Code structure" section (proposed earlier)
Done. Added hyperlinks.
> == "To become a core committer, one needs to sign CLA."
>
> * the above sentence makes one think the CLA is ready, the page makes
> one think it isn't yet "This CLA will be based on Apache's". Clarify ?
I was shooting for ratifying both this and CLA at the same time. More
about this in a separate e-mail.
> == "Core committers are expected to be attentive to pending pull
> requests, and try to act on them quickly."
>
> this is also valid for plugin writers, isn't it ?
I think this is covered more extensively in the "Using pull requests"
section in the end, so I think it's OK.
> == Core coding conventions
>
> "We roughly followSun coding convention
> <http://www.oracle.com/technetwork/java/codeconv-138413.html>in the
> source code, and we use 4 space indentation and don’t use tabs. However,
> we do not believe in rigorously enforcing coding convention, and we
> don’t want to turn down contributions because their code format doesn’t
> match what we use. So consider this informational."
>
> Maybe add something alon "It's generally more practical and appreciated
> if you submit changes that don't change the code format too much as it
> eases the coding review job. Try submitting formatting changes and
> functional changes in separate commits."
Added. This is also discussed in the "Using pull requests" section.