I think everyone that is familiar with Foreman's code base is probably
aware of the many differences in style, structure, and (especially) tests
our project has. It's not illegible if you're familiar with several ways of
doing things, but I believe we should try to standardize things a bit.
On another train of thought, I think new contributors would appreciate this
document and it'd help them to have a document with some guidelines in case
they have doubts about how to write code for this project.
This is just a small draft I decided to wrote after jotting down notes on a
file on my computer for months. It definitely misses a lot of things,
particularly I'm unclear about what's our position on:
Are you guys currently using bbatsov's Ruby and Rails guides? We are using them in Katello although I think there may be a couple things in the Rails guide we don't conform to.
I think it's a great idea if Foreman uses these guides though. We use them in Katello and having developers be able to write Ruby code with the same style in both projects should be very convenient.
David
···
----- Original Message -----
> From: "Daniel Lobato"
> To: foreman-dev@googlegroups.com
> Sent: Thursday, August 7, 2014 3:58:48 PM
> Subject: [foreman-dev] Contributing guidelines draft - proposal
>
> Hi Foremen,
>
> I think everyone that is familiar with Foreman's code base is probably
> aware of the many differences in style, structure, and (especially) tests
> our project has. It's not illegible if you're familiar with several ways of
> doing things, but I believe we should try to standardize things a bit.
>
> On another train of thought, I think new contributors would appreciate this
> document and it'd help them to have a document with some guidelines in case
> they have doubts about how to write code for this project.
>
> This is just a small draft I decided to wrote after jotting down notes on a
> file on my computer for months. It definitely misses a lot of things,
> particularly I'm unclear about what's our position on:
>
> Integration testing
> Javascript code
> Javascript testing
> Stylesheets code
> Benchmarking
>
> I'd really appreciate comments, additions, clarifications... anything. In
> fact if you oppose to having a Coding Standard I'd like to know why too.
>
> https://github.com/eLobato/foreman/blob/develop/CONTRIBUTING.md
>
> Thank you,
>
> --
> Daniel Lobato
>
> @elobatoss
> blog.daniellobato.me
> daniellobato.me
>
> GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
I don't think we are, at least officially, the CONTRIBUTING document I
linked to states that, just as a proposal that some day might be in Foreman
itself (it's linked to my own fork).
Ideally we can use the PR processor to run rubocop and check this stuff
automatically.
···
On Thu, Aug 7, 2014 at 10:27 PM, David Davis wrote:
Are you guys currently using bbatsov’s Ruby and Rails guides? We are using
them in Katello although I think there may be a couple things in the Rails
guide we don’t conform to.
I think it’s a great idea if Foreman uses these guides though. We use them
in Katello and having developers be able to write Ruby code with the same
style in both projects should be very convenient.
I think everyone that is familiar with Foreman’s code base is probably
aware of the many differences in style, structure, and (especially) tests
our project has. It’s not illegible if you’re familiar with several ways
of
doing things, but I believe we should try to standardize things a bit.
On another train of thought, I think new contributors would appreciate
this
document and it’d help them to have a document with some guidelines in
case
they have doubts about how to write code for this project.
This is just a small draft I decided to wrote after jotting down notes
on a
file on my computer for months. It definitely misses a lot of things,
particularly I’m unclear about what’s our position on:
You beat me to the punch, and since you sent yours out first I'll post
some thoughts I've had. I, similar to you, started to try to integrate
the Katello contributions docs and the Foreman ones to try to form a
cohesive contribution guide with solid examples. This is where I got
to before I saw your email - https://github.com/ehelms/theforeman.org/blob/commit-docs/contribute.md.
Some thoughts and suggestions:
Keep the full contributing documentation in theforeman.org github
Makes it easier to review and allows commenting
Since these guidelines are meant to apply to all the repositories
within the umbrella, centralizing makes it easier to find and point to
from other repositories
Keep CONTRIBUTING.md concise with the basic steps of the process
and links to the full official documentation for each step of the
process
Separate out style guides to their own sections within theforeman.org documentation
Tackle each individually (contributing guidelines, ruby style,
javascript style, puppet style) - automate where possible and document
how to run
Attempt to combine the Foreman and Katello documentation on these
areas to provide community cohesiveness
Providing the same process and guidelines across sub-projects will
make contributing from one to the other easier for users
Some Katello docs we've developed over the years for reference:
Into a single cohesive document that, similar to contributing patches,
has a short section with the basics and detailed breakout.
We could easily split this up amongst a few developers that are
interested in order to break-up the work load. I for one am more than
willing to tackle some pieces if you'd like.
Eric
···
On Thu, Aug 7, 2014 at 5:19 PM, Daniel Lobato wrote:
> I don't think we are, at least officially, the CONTRIBUTING document I
> linked to states that, just as a proposal that some day might be in Foreman
> itself (it's linked to my own fork).
>
> Ideally we can use the PR processor to run rubocop and check this stuff
> automatically.
>
>
> On Thu, Aug 7, 2014 at 10:27 PM, David Davis wrote:
>>
>> Are you guys currently using bbatsov's Ruby and Rails guides? We are using
>> them in Katello although I think there may be a couple things in the Rails
>> guide we don't conform to.
>>
>> I think it's a great idea if Foreman uses these guides though. We use them
>> in Katello and having developers be able to write Ruby code with the same
>> style in both projects should be very convenient.
>>
>> David
>>
>> ----- Original Message -----
>> > From: "Daniel Lobato"
>> > To: foreman-dev@googlegroups.com
>> > Sent: Thursday, August 7, 2014 3:58:48 PM
>> > Subject: [foreman-dev] Contributing guidelines draft - proposal
>> >
>> > Hi Foremen,
>> >
>> > I think everyone that is familiar with Foreman's code base is probably
>> > aware of the many differences in style, structure, and (especially)
>> tests
>> > our project has. It's not illegible if you're familiar with several ways
>> of
>> > doing things, but I believe we should try to standardize things a bit.
>> >
>> > On another train of thought, I think new contributors would appreciate
>> this
>> > document and it'd help them to have a document with some guidelines in
>> case
>> > they have doubts about how to write code for this project.
>> >
>> > This is just a small draft I decided to wrote after jotting down notes
>> on a
>> > file on my computer for months. It definitely misses a lot of things,
>> > particularly I'm unclear about what's our position on:
>> >
>> > Integration testing
>> > Javascript code
>> > Javascript testing
>> > Stylesheets code
>> > Benchmarking
>> >
>> > I'd really appreciate comments, additions, clarifications... anything.
>> In
>> > fact if you oppose to having a Coding Standard I'd like to know why too.
>> >
>> > https://github.com/eLobato/foreman/blob/develop/CONTRIBUTING.md
>> >
>> > Thank you,
>> >
>> > --
>> > Daniel Lobato
>> >
>> > @elobatoss
>> > blog.daniellobato.me
>> > daniellobato.me
>> >
>> > GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "foreman-dev" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to foreman-dev+unsubscribe@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>> >
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "foreman-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to foreman-dev+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Daniel Lobato
>
> @elobatoss
> blog.daniellobato.me
> daniellobato.me
>
> GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
1,2,3: Agreed, for the moment I think it's fine to try to gather all our
thoughts in one document then we figure out how to deliver it, what you say
about linking to the actual documentation on theforeman.org sounds good to
me. I for one have noticed people often get confused at our seemingly empty
of information Github page (no wiki, no readme, no contributing docs) and
ask questions on IRC that would have been easily found there. We probably
would want to have a similar document in all repos, conveniently linking to
the relevant information. For instance in puppet-foreman we should
emphasize and link to the Puppet style guide.
I think we can reuse Katello's Rubocop jobs for Ruby. For Javascript,
I'd like to get someone on board more knowledgeable than myself. I'm not
sure how many people agree with the tacit agreement that we don't test
Javascript code. For Puppet puppet-lint is a fine tool, although I can say
I'm not the happiest with how little it is maintained.
Last but not least, the longer we delay this the more code we'll have to
standardize when (if?) we do this.
···
On Fri, Aug 8, 2014 at 4:41 AM, Eric D Helms wrote:
You beat me to the punch, and since you sent yours out first I’ll post
some thoughts I’ve had. I, similar to you, started to try to integrate
the Katello contributions docs and the Foreman ones to try to form a
cohesive contribution guide with solid examples. This is where I got
to before I saw your email - https://github.com/ehelms/theforeman.org/blob/commit-docs/contribute.md.
Some thoughts and suggestions:
Keep the full contributing documentation in theforeman.org github
Makes it easier to review and allows commenting
Since these guidelines are meant to apply to all the repositories
within the umbrella, centralizing makes it easier to find and point to
from other repositories
Keep CONTRIBUTING.md concise with the basic steps of the process
and links to the full official documentation for each step of the
process
Separate out style guides to their own sections within theforeman.org documentation
Tackle each individually (contributing guidelines, ruby style,
javascript style, puppet style) - automate where possible and document
how to run
Attempt to combine the Foreman and Katello documentation on these
areas to provide community cohesiveness
Providing the same process and guidelines across sub-projects will
make contributing from one to the other easier for users
Some Katello docs we’ve developed over the years for reference:
Into a single cohesive document that, similar to contributing patches,
has a short section with the basics and detailed breakout.
We could easily split this up amongst a few developers that are
interested in order to break-up the work load. I for one am more than
willing to tackle some pieces if you’d like.
I don’t think we are, at least officially, the CONTRIBUTING document I
linked to states that, just as a proposal that some day might be in
Foreman
itself (it’s linked to my own fork).
Ideally we can use the PR processor to run rubocop and check this stuff
automatically.
I think everyone that is familiar with Foreman’s code base is probably
aware of the many differences in style, structure, and (especially)
tests
our project has. It’s not illegible if you’re familiar with several
ways
of
doing things, but I believe we should try to standardize things a bit.
On another train of thought, I think new contributors would appreciate
this
document and it’d help them to have a document with some guidelines in
case
they have doubts about how to write code for this project.
This is just a small draft I decided to wrote after jotting down notes
on a
file on my computer for months. It definitely misses a lot of things,
particularly I’m unclear about what’s our position on:
Question for Katello devs - are you running these checks against only the
changes in new PRs, or you run it against the whole code base in every PR?
···
On Mon, Aug 11, 2014 at 2:25 AM, Daniel Lobato wrote:
Eric,
1,2,3: Agreed, for the moment I think it’s fine to try to gather all our
thoughts in one document then we figure out how to deliver it, what you say
about linking to the actual documentation on theforeman.org sounds good
to me. I for one have noticed people often get confused at our seemingly
empty of information Github page (no wiki, no readme, no contributing docs)
and ask questions on IRC that would have been easily found there. We
probably would want to have a similar document in all repos, conveniently
linking to the relevant information. For instance in puppet-foreman we
should emphasize and link to the Puppet style guide.
I think we can reuse Katello’s Rubocop jobs for Ruby. For Javascript,
I’d like to get someone on board more knowledgeable than myself. I’m not
sure how many people agree with the tacit agreement that we don’t test
Javascript code. For Puppet puppet-lint is a fine tool, although I can say
I’m not the happiest with how little it is maintained.
You beat me to the punch, and since you sent yours out first I’ll post
some thoughts I’ve had. I, similar to you, started to try to integrate
the Katello contributions docs and the Foreman ones to try to form a
cohesive contribution guide with solid examples. This is where I got
to before I saw your email - https://github.com/ehelms/theforeman.org/blob/commit-docs/contribute.md.
Some thoughts and suggestions:
Keep the full contributing documentation in theforeman.org github
Makes it easier to review and allows commenting
Since these guidelines are meant to apply to all the repositories
within the umbrella, centralizing makes it easier to find and point to
from other repositories
Keep CONTRIBUTING.md concise with the basic steps of the process
and links to the full official documentation for each step of the
process
Separate out style guides to their own sections within theforeman.org documentation
Tackle each individually (contributing guidelines, ruby style,
javascript style, puppet style) - automate where possible and document
how to run
Attempt to combine the Foreman and Katello documentation on these
areas to provide community cohesiveness
Providing the same process and guidelines across sub-projects will
make contributing from one to the other easier for users
Some Katello docs we’ve developed over the years for reference:
Into a single cohesive document that, similar to contributing patches,
has a short section with the basics and detailed breakout.
We could easily split this up amongst a few developers that are
interested in order to break-up the work load. I for one am more than
willing to tackle some pieces if you’d like.
I don’t think we are, at least officially, the CONTRIBUTING document I
linked to states that, just as a proposal that some day might be in
Foreman
itself (it’s linked to my own fork).
Ideally we can use the PR processor to run rubocop and check this stuff
automatically.
–
You received this message because you are subscribed to the Google
Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send
We run the checks against the whole code base in every PR.
For Javascript we use JSHint [1] for linting and Jasmine/Karma [2] for testing. For HTML we use HTMLHhint [3] for linting. There is also a CSSLint [4] for CSS but we don't currently use it.
Using grunt [5] makes running these tasks a lot easier.
1,2,3: Agreed, for the moment I think it’s fine to try to gather all our
thoughts in one document then we figure out how to deliver it, what you say
about linking to the actual documentation on theforeman.org sounds good
to me. I for one have noticed people often get confused at our seemingly
empty of information Github page (no wiki, no readme, no contributing docs)
and ask questions on IRC that would have been easily found there. We
probably would want to have a similar document in all repos, conveniently
linking to the relevant information. For instance in puppet-foreman we
should emphasize and link to the Puppet style guide.
I think we can reuse Katello’s Rubocop jobs for Ruby. For Javascript,
I’d like to get someone on board more knowledgeable than myself. I’m not
sure how many people agree with the tacit agreement that we don’t test
Javascript code. For Puppet puppet-lint is a fine tool, although I can say
I’m not the happiest with how little it is maintained.
You beat me to the punch, and since you sent yours out first I’ll post
some thoughts I’ve had. I, similar to you, started to try to integrate
the Katello contributions docs and the Foreman ones to try to form a
cohesive contribution guide with solid examples. This is where I got
to before I saw your email - https://github.com/ehelms/theforeman.org/blob/commit-docs/contribute.md.
Some thoughts and suggestions:
Keep the full contributing documentation in theforeman.org github
Makes it easier to review and allows commenting
Since these guidelines are meant to apply to all the repositories
within the umbrella, centralizing makes it easier to find and point to
from other repositories
Keep CONTRIBUTING.md concise with the basic steps of the process
and links to the full official documentation for each step of the
process
Separate out style guides to their own sections within theforeman.org documentation
Tackle each individually (contributing guidelines, ruby style,
javascript style, puppet style) - automate where possible and document
how to run
Attempt to combine the Foreman and Katello documentation on these
areas to provide community cohesiveness
Providing the same process and guidelines across sub-projects will
make contributing from one to the other easier for users
Some Katello docs we’ve developed over the years for reference:
Into a single cohesive document that, similar to contributing patches,
has a short section with the basics and detailed breakout.
We could easily split this up amongst a few developers that are
interested in order to break-up the work load. I for one am more than
willing to tackle some pieces if you’d like.
I don’t think we are, at least officially, the CONTRIBUTING document I
linked to states that, just as a proposal that some day might be in
Foreman
itself (it’s linked to my own fork).
Ideally we can use the PR processor to run rubocop and check this stuff
automatically.
–
You received this message because you are subscribed to the Google
Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send
