metron-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Miklavcic (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (METRON-1071) Create CONTRIBUTING.md
Date Tue, 01 Aug 2017 17:11:01 GMT

    [ https://issues.apache.org/jira/browse/METRON-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16109306#comment-16109306
] 

Michael Miklavcic commented on METRON-1071:
-------------------------------------------

I'm looking for the best place to put guidance around best practices for things like Maven
and SLF4J. METRON-975 has just been merged (https://github.com/apache/metron/pull/599) along
with METRON-1060 (https://github.com/apache/metron/pull/665).

We have a couple options so far - this CONTRIBUTING.md and the dev guideliness wiki - https://cwiki.apache.org/confluence/display/METRON/Development+Guidelines

Which do we see as the high level guide vs more detailed guide? Otto opined that would should
have a guide for things like testing, perf testing, etc. https://github.com/apache/metron/pull/665#issuecomment-318784009
and I completely agree. I'm wondering if either of the above mentioned locations is suitable
for this, or if we need yet another separate doc. We currently have high level requirements
mixed with low level requirements in our dev guidelines wiki. I think we should consider removing
some of the extremely specific items and place them in a separate topical guide for developers,
though I haven't yet compared our guide to other projects' guides. Thoughts?

> Create CONTRIBUTING.md
> ----------------------
>
>                 Key: METRON-1071
>                 URL: https://issues.apache.org/jira/browse/METRON-1071
>             Project: Metron
>          Issue Type: Improvement
>            Reporter: Justin Leet
>            Assignee: Justin Leet
>
> The idea is to have a document on contributing to Metron that lives alongside our code
(and we can then move away from the wiki).  This document should have a couple things in it:
> * What we look for from code contributions
> * How people can actually contribute code
> * How people can contribute, even without code (e.g. reviews)
> * Helpful things like setting up Travis on personal repos to avoid full testing time
locally.
> It should also integrate nicely with the site-book, so just make sure everything plays
nicely.
> See: https://github.com/blog/1184-contributing-guidelines



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message