Re: [foreman-dev] Retire the RFC repo?

2017-03-28 Thread Ewoud Kohl van Wijngaarden
On Tue, Mar 28, 2017 at 01:32:02PM +0100, Greg Sutcliffe wrote:
> On Tuesday, 28 March 2017 12:50:14 BST Marek Hulán wrote:
> > > While I agree that we need a better way to end discussions, I think that
> > > on point 1 we can improve as well. To me it feels like we lack
> > > visibility. It has been suggested to move back to the mailing list since
> > > that has more visibility. Others have suggested discussions on github
> > > are easier to read back. I'd suggest that we adopt the github bot to
> > > notify the ML of certain events. Some things I can think of are created,
> > > reached impasse, closed or merged. For reached impasse we could use a
> > > label or [impasse]. A timer could also work.
> > 
> > I like this idea a lot
> 
> So do I, I'd love to see this happen.
> 
> Another suggestion I heard on visibility was to at least cross-post new RFCs 
> to the mailing list as well - this risks fragmenting the discussion, so we'd 
> have to be clear about that, but a simple "hey, there's a new rfc, check it 
> out no replies here" post might be useful?

This would be an implementation of the created event. To prevent a split
discussion the bot could avoid sending the full message. Initially I was
thinking of the subject but maybe there's an easy way to get the first
paragraph as a teaser.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [foreman-dev] Retire the RFC repo?

2017-03-28 Thread Greg Sutcliffe
On Tuesday, 28 March 2017 12:50:14 BST Marek Hulán wrote:
> > While I agree that we need a better way to end discussions, I think that
> > on point 1 we can improve as well. To me it feels like we lack
> > visibility. It has been suggested to move back to the mailing list since
> > that has more visibility. Others have suggested discussions on github
> > are easier to read back. I'd suggest that we adopt the github bot to
> > notify the ML of certain events. Some things I can think of are created,
> > reached impasse, closed or merged. For reached impasse we could use a
> > label or [impasse]. A timer could also work.
> 
> I like this idea a lot

So do I, I'd love to see this happen.

Another suggestion I heard on visibility was to at least cross-post new RFCs 
to the mailing list as well - this risks fragmenting the discussion, so we'd 
have to be clear about that, but a simple "hey, there's a new rfc, check it 
out no replies here" post might be useful?

Greg

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [foreman-dev] Retire the RFC repo?

2017-03-28 Thread Marek Hulán
On úterý 28. března 2017 13:38:31 CEST Ewoud Kohl van Wijngaarden wrote:
> On Tue, Mar 21, 2017 at 03:39:45PM +, Greg Sutcliffe wrote:
> > I've been meaning to reply to this for about a week, sorry for the delay.
> > This is a topic I've been thinking about for a *long* time, so apologies
> > for the long thread :P
> 
> Let me be even later to the party.
> 
> > I think there's two issues here. One is *how* to have the discussion, and
> > the other is how to *end* the discussion. From the comments so far, it
> > seems we're still somewhat split on point 1, but we're all agreed we need
> > to find a solution to point 2. As such, I'm only going to discuss point
> > 2, as that's where we currently struggle.
> 
> While I agree that we need a better way to end discussions, I think that
> on point 1 we can improve as well. To me it feels like we lack
> visibility. It has been suggested to move back to the mailing list since
> that has more visibility. Others have suggested discussions on github
> are easier to read back. I'd suggest that we adopt the github bot to
> notify the ML of certain events. Some things I can think of are created,
> reached impasse, closed or merged. For reached impasse we could use a
> label or [impasse]. A timer could also work.

I like this idea a lot

--
Marek

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [foreman-dev] Retire the RFC repo?

2017-03-28 Thread Ewoud Kohl van Wijngaarden
On Tue, Mar 21, 2017 at 03:39:45PM +, Greg Sutcliffe wrote:
> I've been meaning to reply to this for about a week, sorry for the delay. 
> This 
> is a topic I've been thinking about for a *long* time, so apologies for the 
> long thread :P

Let me be even later to the party.

> I think there's two issues here. One is *how* to have the discussion, and the 
> other is how to *end* the discussion. From the comments so far, it seems 
> we're 
> still somewhat split on point 1, but we're all agreed we need to find a 
> solution to point 2. As such, I'm only going to discuss point 2, as that's 
> where we currently struggle.

While I agree that we need a better way to end discussions, I think that
on point 1 we can improve as well. To me it feels like we lack
visibility. It has been suggested to move back to the mailing list since
that has more visibility. Others have suggested discussions on github
are easier to read back. I'd suggest that we adopt the github bot to
notify the ML of certain events. Some things I can think of are created,
reached impasse, closed or merged. For reached impasse we could use a
label or [impasse]. A timer could also work.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [foreman-dev] Retire the RFC repo?

2017-03-22 Thread Lukas Zapletal
I find email (properly tagged) more comfortable than github or wiki,
but I can live with current status if folks prefer. So you can bucket
me in "keep as is".

LZ

On Tue, Mar 21, 2017 at 4:39 PM, Greg Sutcliffe
 wrote:
> I've been meaning to reply to this for about a week, sorry for the delay. This
> is a topic I've been thinking about for a *long* time, so apologies for the
> long thread :P
>
> I think there's two issues here. One is *how* to have the discussion, and the
> other is how to *end* the discussion. From the comments so far, it seems we're
> still somewhat split on point 1, but we're all agreed we need to find a
> solution to point 2. As such, I'm only going to discuss point 2, as that's
> where we currently struggle.
>
> For ways to end a discussion, I think there are several options. I've stayed
> away from this area for a while, because it can be fairly explosive, but it's
> clear we do need a way to conclude a discussion.
>
> One choice is to have a group of people responsible for deciding on these
> things (a "technical council" or whatever title you wish to use). There's no
> doubt that this works, but I dislike this option but it's exclusive, requires
> a great deal of overhead (particularly documenting how the group works, and
> how to become a part of it, and so forth). As a data point, Libreoffice do
> this, with a similar order-of-magnitude of regular contributors.
>
> Another is a simple vote, but then you have to balance the "when" and "how".
> Preserving the "quieter voices" (that is, people whose expertise is valuable,
> but who don;t want to wade into a big discussion) in our community is
> important, and votes are good for this, but close-to-50% votes can be very
> divisive. PHP use this method, with the extra clause that the author of the
> RFC gets to call the vote (after a minimum wait of 1 week from opening), and
> they find it works for them.
>
> We could also turn to 3rd party systems to help us with discussions - as an
> example, I believe the Diaspora development community use Loomio for their
> decision making, but I have no data on how well it's working for them. I#m not
> for this option - we already use enough tools - but others may like the idea.
>
> At this time, my gut feeling is:
>
> a) The group is split on the RFC repo, so let's not call it dead yet
> b) The RFC repo works well(ish) as a place to discuss design
> c) It needs process improvements to reflect how it's *actually* being used
> d) We could add the vote system from PHP for closing discussions
> e) (tangent) We could also use said vote system for foreman-dev discussions
>
> As further info, here's the recording from my discussion at FOSDEM on this
> topic (where the above comments about Libreoffice and PHP come from, but
> there's a lot of interesting stuff in there):
>
> http://mirror.onet.pl/pub/mirrors/video.fosdem.org/2017/UD2.119/
> community_closing_loops.mp4
>
> So, to the point - how would people feel about trialing this? We'd need to
> decide (a) if we want to test it, (b) how to call for & record votes, and (c)
> when to end the trial and decide on whether to keep it. If you're against this
> idea, please do suggest how else we might collectively improve our ways to
> finish discussions :)
>
> Cheers
> Greg
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Later,
  Lukas @lzap Zapletal

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [foreman-dev] Retire the RFC repo?

2017-03-21 Thread Greg Sutcliffe
I've been meaning to reply to this for about a week, sorry for the delay. This 
is a topic I've been thinking about for a *long* time, so apologies for the 
long thread :P

I think there's two issues here. One is *how* to have the discussion, and the 
other is how to *end* the discussion. From the comments so far, it seems we're 
still somewhat split on point 1, but we're all agreed we need to find a 
solution to point 2. As such, I'm only going to discuss point 2, as that's 
where we currently struggle.

For ways to end a discussion, I think there are several options. I've stayed 
away from this area for a while, because it can be fairly explosive, but it's 
clear we do need a way to conclude a discussion.

One choice is to have a group of people responsible for deciding on these 
things (a "technical council" or whatever title you wish to use). There's no 
doubt that this works, but I dislike this option but it's exclusive, requires 
a great deal of overhead (particularly documenting how the group works, and 
how to become a part of it, and so forth). As a data point, Libreoffice do 
this, with a similar order-of-magnitude of regular contributors.

Another is a simple vote, but then you have to balance the "when" and "how". 
Preserving the "quieter voices" (that is, people whose expertise is valuable, 
but who don;t want to wade into a big discussion) in our community is 
important, and votes are good for this, but close-to-50% votes can be very 
divisive. PHP use this method, with the extra clause that the author of the 
RFC gets to call the vote (after a minimum wait of 1 week from opening), and 
they find it works for them. 

We could also turn to 3rd party systems to help us with discussions - as an 
example, I believe the Diaspora development community use Loomio for their 
decision making, but I have no data on how well it's working for them. I#m not 
for this option - we already use enough tools - but others may like the idea.

At this time, my gut feeling is:

a) The group is split on the RFC repo, so let's not call it dead yet
b) The RFC repo works well(ish) as a place to discuss design
c) It needs process improvements to reflect how it's *actually* being used
d) We could add the vote system from PHP for closing discussions
e) (tangent) We could also use said vote system for foreman-dev discussions

As further info, here's the recording from my discussion at FOSDEM on this 
topic (where the above comments about Libreoffice and PHP come from, but 
there's a lot of interesting stuff in there):

http://mirror.onet.pl/pub/mirrors/video.fosdem.org/2017/UD2.119/
community_closing_loops.mp4

So, to the point - how would people feel about trialing this? We'd need to 
decide (a) if we want to test it, (b) how to call for & record votes, and (c) 
when to end the trial and decide on whether to keep it. If you're against this 
idea, please do suggest how else we might collectively improve our ways to 
finish discussions :)

Cheers
Greg

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [foreman-dev] Retire the RFC repo?

2017-03-15 Thread Perry Gagne
I also have not made a contribution to the RFC repo, but from time to time
have read others. I like the idea of the RFC repo, but wonder if it could
be better organized.

One frustration I have with it is it is if you want to get a full idea of
new and upcoming ideas, you have to browse each individual fork and there
is no central index page.

Perhaps some sort of wiki-like page with a central index of both "accepted"
and "in progress" rfcs would be better?

Thoughts?



On Wed, Mar 15, 2017 at 9:00 AM, John Mitsch  wrote:

> I have an open design in the RFC repo that contains screenshots and
> feedback that I still plan to implement. I've kept it open due to some
> refactoring that has to happen before it can be implemented.
>
> I like having a central place that I can design out a feature with other
> developers and UX team. Its nice to be able to refer back to it months
> later without having to hunt down a thread and scroll through it. It also
> makes linking to screenshots and comments much easier.
>
> I'm also open to other suggestions besides the mailing list, but my vote
> is to keep the RFC repo
>
> John Mitsch
> Red Hat Engineering
> (860)-967-7285 <(860)%20967-7285>
> irc: jomitsch
>
> On Wed, Mar 15, 2017 at 8:07 AM, Eric D Helms 
> wrote:
>
>> I also like the RFC repository. I have not merged or closed a lot of my
>> RFCs because I consider the designs to still be open discussions that need
>> re-visting and continued visibility. The ability to comment on specific
>> issues and have multiple threads going makes it much easier to follow than
>> a mailing list email IMO.
>>
>> On Wed, Mar 15, 2017 at 7:57 AM, Justin Sherrill 
>> wrote:
>>
>>>
>>>
>>> On 03/13/2017 07:10 AM, Tomas Strachota wrote:
>>>
 For me the biggest advantage of RFC repo over design discussions on
 mailing list is that when you come back to it later, you immediately
 see the latest state of the proposal without any need for reading
 through the whole email thread. At the same time, when you what to see
 the whole discussion you can display the outdated comments and older
 commits. Sending/receiving comments in form of code reviews is quite
 natural for me, but that's matter of personal preference.

 In my opinion both described issues (RFCs not being closed and design
 decisions without RFCs) aren't connected with github reviews but with
 the process around. Moving back to mailing lists won't help us with
 that. Therefore I'd keep RFC repo and rather work on defining how we
 decide on accepting/rejecting RFCs and who's responsible for keeping
 an eye on that.

>>> I also like the RFC repo.  As someone that opened an RFC but never
>>> 'closed' it, it was mostly due to time, but I still plan to revisit it in
>>> the future. I'm not sure that its a 'bad' thing to have open RFCs (although
>>> we could auto close them after some months of inactivity).  Similarly on
>>> the mailing list you'd just end up with discussions that never go anywhere.
>>>
>>> I'd be interested in other proposals, but like Tomas said, I don't think
>>> moving to the mailing list would solve many of the issues.
>>>
>>> -Justin
>>>
>>>
>>>
>>>
 T.

 On Sun, Mar 12, 2017 at 9:52 AM, Tomer Brisker 
 wrote:

> Hello,
>
> About a year ago, we decided to try using a new system for discussing
> design
> decisions prior to making changes, by creating a repo for RFCs [1].
> Part of
> the problem was that when discussing on the mailing list, discussions
> tended
> to die out without a resolution, and eventually whoever wrote the code
> made
> the decision (or not).
> Since then, there have been about 30 proposals made in the repository.
> 22 of
> them are still open, most with no activity for months.
> So I feel fairly safe to say that this change has not led to the wanted
> result of getting decisions made faster or with more discussion. A
> significant part of the proposals have less then 10 comments, in many
> cases
> all from just one or two respondents. Eventually proposals are still
> decided
> on only when someone goes ahead, writes the code and gets it merged.
> This has also led to some discussions taking place without all of the
> developers even knowing about them, as it would seem most don't follow
> that
> repo regularly, leading to repeated discussions when a PR is created.
> In addition, some design decisions are still being made without going
> through the RFC process, either by mailing list discussions or by
> people
> just creating PRs without any prior discussion.
>
> I'm not sure what we can do to increase peoples' involvement in these
> discussions, nor what would be a better way of making design
> decisions, but
> let's try to figure it out since this attempt has not worked out as
> expected
> in my opinion.
>
> [1] 

Re: [foreman-dev] Retire the RFC repo?

2017-03-15 Thread John Mitsch
I have an open design in the RFC repo that contains screenshots and
feedback that I still plan to implement. I've kept it open due to some
refactoring that has to happen before it can be implemented.

I like having a central place that I can design out a feature with other
developers and UX team. Its nice to be able to refer back to it months
later without having to hunt down a thread and scroll through it. It also
makes linking to screenshots and comments much easier.

I'm also open to other suggestions besides the mailing list, but my vote is
to keep the RFC repo

John Mitsch
Red Hat Engineering
(860)-967-7285
irc: jomitsch

On Wed, Mar 15, 2017 at 8:07 AM, Eric D Helms  wrote:

> I also like the RFC repository. I have not merged or closed a lot of my
> RFCs because I consider the designs to still be open discussions that need
> re-visting and continued visibility. The ability to comment on specific
> issues and have multiple threads going makes it much easier to follow than
> a mailing list email IMO.
>
> On Wed, Mar 15, 2017 at 7:57 AM, Justin Sherrill 
> wrote:
>
>>
>>
>> On 03/13/2017 07:10 AM, Tomas Strachota wrote:
>>
>>> For me the biggest advantage of RFC repo over design discussions on
>>> mailing list is that when you come back to it later, you immediately
>>> see the latest state of the proposal without any need for reading
>>> through the whole email thread. At the same time, when you what to see
>>> the whole discussion you can display the outdated comments and older
>>> commits. Sending/receiving comments in form of code reviews is quite
>>> natural for me, but that's matter of personal preference.
>>>
>>> In my opinion both described issues (RFCs not being closed and design
>>> decisions without RFCs) aren't connected with github reviews but with
>>> the process around. Moving back to mailing lists won't help us with
>>> that. Therefore I'd keep RFC repo and rather work on defining how we
>>> decide on accepting/rejecting RFCs and who's responsible for keeping
>>> an eye on that.
>>>
>> I also like the RFC repo.  As someone that opened an RFC but never
>> 'closed' it, it was mostly due to time, but I still plan to revisit it in
>> the future. I'm not sure that its a 'bad' thing to have open RFCs (although
>> we could auto close them after some months of inactivity).  Similarly on
>> the mailing list you'd just end up with discussions that never go anywhere.
>>
>> I'd be interested in other proposals, but like Tomas said, I don't think
>> moving to the mailing list would solve many of the issues.
>>
>> -Justin
>>
>>
>>
>>
>>> T.
>>>
>>> On Sun, Mar 12, 2017 at 9:52 AM, Tomer Brisker 
>>> wrote:
>>>
 Hello,

 About a year ago, we decided to try using a new system for discussing
 design
 decisions prior to making changes, by creating a repo for RFCs [1].
 Part of
 the problem was that when discussing on the mailing list, discussions
 tended
 to die out without a resolution, and eventually whoever wrote the code
 made
 the decision (or not).
 Since then, there have been about 30 proposals made in the repository.
 22 of
 them are still open, most with no activity for months.
 So I feel fairly safe to say that this change has not led to the wanted
 result of getting decisions made faster or with more discussion. A
 significant part of the proposals have less then 10 comments, in many
 cases
 all from just one or two respondents. Eventually proposals are still
 decided
 on only when someone goes ahead, writes the code and gets it merged.
 This has also led to some discussions taking place without all of the
 developers even knowing about them, as it would seem most don't follow
 that
 repo regularly, leading to repeated discussions when a PR is created.
 In addition, some design decisions are still being made without going
 through the RFC process, either by mailing list discussions or by people
 just creating PRs without any prior discussion.

 I'm not sure what we can do to increase peoples' involvement in these
 discussions, nor what would be a better way of making design decisions,
 but
 let's try to figure it out since this attempt has not worked out as
 expected
 in my opinion.

 [1] original discussion -
 https://groups.google.com/forum/#!msg/foreman-dev/P9uRYV5K1D
 c/xKMnzOOqDgAJ

 --
 Have a nice day,
 Tomer Brisker
 Red Hat Engineering

 --
 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+unsubscr...@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 

Re: [foreman-dev] Retire the RFC repo?

2017-03-15 Thread Eric D Helms
I also like the RFC repository. I have not merged or closed a lot of my
RFCs because I consider the designs to still be open discussions that need
re-visting and continued visibility. The ability to comment on specific
issues and have multiple threads going makes it much easier to follow than
a mailing list email IMO.

On Wed, Mar 15, 2017 at 7:57 AM, Justin Sherrill 
wrote:

>
>
> On 03/13/2017 07:10 AM, Tomas Strachota wrote:
>
>> For me the biggest advantage of RFC repo over design discussions on
>> mailing list is that when you come back to it later, you immediately
>> see the latest state of the proposal without any need for reading
>> through the whole email thread. At the same time, when you what to see
>> the whole discussion you can display the outdated comments and older
>> commits. Sending/receiving comments in form of code reviews is quite
>> natural for me, but that's matter of personal preference.
>>
>> In my opinion both described issues (RFCs not being closed and design
>> decisions without RFCs) aren't connected with github reviews but with
>> the process around. Moving back to mailing lists won't help us with
>> that. Therefore I'd keep RFC repo and rather work on defining how we
>> decide on accepting/rejecting RFCs and who's responsible for keeping
>> an eye on that.
>>
> I also like the RFC repo.  As someone that opened an RFC but never
> 'closed' it, it was mostly due to time, but I still plan to revisit it in
> the future. I'm not sure that its a 'bad' thing to have open RFCs (although
> we could auto close them after some months of inactivity).  Similarly on
> the mailing list you'd just end up with discussions that never go anywhere.
>
> I'd be interested in other proposals, but like Tomas said, I don't think
> moving to the mailing list would solve many of the issues.
>
> -Justin
>
>
>
>
>> T.
>>
>> On Sun, Mar 12, 2017 at 9:52 AM, Tomer Brisker 
>> wrote:
>>
>>> Hello,
>>>
>>> About a year ago, we decided to try using a new system for discussing
>>> design
>>> decisions prior to making changes, by creating a repo for RFCs [1]. Part
>>> of
>>> the problem was that when discussing on the mailing list, discussions
>>> tended
>>> to die out without a resolution, and eventually whoever wrote the code
>>> made
>>> the decision (or not).
>>> Since then, there have been about 30 proposals made in the repository.
>>> 22 of
>>> them are still open, most with no activity for months.
>>> So I feel fairly safe to say that this change has not led to the wanted
>>> result of getting decisions made faster or with more discussion. A
>>> significant part of the proposals have less then 10 comments, in many
>>> cases
>>> all from just one or two respondents. Eventually proposals are still
>>> decided
>>> on only when someone goes ahead, writes the code and gets it merged.
>>> This has also led to some discussions taking place without all of the
>>> developers even knowing about them, as it would seem most don't follow
>>> that
>>> repo regularly, leading to repeated discussions when a PR is created.
>>> In addition, some design decisions are still being made without going
>>> through the RFC process, either by mailing list discussions or by people
>>> just creating PRs without any prior discussion.
>>>
>>> I'm not sure what we can do to increase peoples' involvement in these
>>> discussions, nor what would be a better way of making design decisions,
>>> but
>>> let's try to figure it out since this attempt has not worked out as
>>> expected
>>> in my opinion.
>>>
>>> [1] original discussion -
>>> https://groups.google.com/forum/#!msg/foreman-dev/P9uRYV5K1D
>>> c/xKMnzOOqDgAJ
>>>
>>> --
>>> Have a nice day,
>>> Tomer Brisker
>>> Red Hat Engineering
>>>
>>> --
>>> 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+unsubscr...@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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Eric D. Helms
Red Hat Engineering

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [foreman-dev] Retire the RFC repo?

2017-03-15 Thread Justin Sherrill



On 03/13/2017 07:10 AM, Tomas Strachota wrote:

For me the biggest advantage of RFC repo over design discussions on
mailing list is that when you come back to it later, you immediately
see the latest state of the proposal without any need for reading
through the whole email thread. At the same time, when you what to see
the whole discussion you can display the outdated comments and older
commits. Sending/receiving comments in form of code reviews is quite
natural for me, but that's matter of personal preference.

In my opinion both described issues (RFCs not being closed and design
decisions without RFCs) aren't connected with github reviews but with
the process around. Moving back to mailing lists won't help us with
that. Therefore I'd keep RFC repo and rather work on defining how we
decide on accepting/rejecting RFCs and who's responsible for keeping
an eye on that.
I also like the RFC repo.  As someone that opened an RFC but never 
'closed' it, it was mostly due to time, but I still plan to revisit it 
in the future. I'm not sure that its a 'bad' thing to have open RFCs 
(although we could auto close them after some months of inactivity).  
Similarly on the mailing list you'd just end up with discussions that 
never go anywhere.


I'd be interested in other proposals, but like Tomas said, I don't think 
moving to the mailing list would solve many of the issues.


-Justin




T.

On Sun, Mar 12, 2017 at 9:52 AM, Tomer Brisker  wrote:

Hello,

About a year ago, we decided to try using a new system for discussing design
decisions prior to making changes, by creating a repo for RFCs [1]. Part of
the problem was that when discussing on the mailing list, discussions tended
to die out without a resolution, and eventually whoever wrote the code made
the decision (or not).
Since then, there have been about 30 proposals made in the repository. 22 of
them are still open, most with no activity for months.
So I feel fairly safe to say that this change has not led to the wanted
result of getting decisions made faster or with more discussion. A
significant part of the proposals have less then 10 comments, in many cases
all from just one or two respondents. Eventually proposals are still decided
on only when someone goes ahead, writes the code and gets it merged.
This has also led to some discussions taking place without all of the
developers even knowing about them, as it would seem most don't follow that
repo regularly, leading to repeated discussions when a PR is created.
In addition, some design decisions are still being made without going
through the RFC process, either by mailing list discussions or by people
just creating PRs without any prior discussion.

I'm not sure what we can do to increase peoples' involvement in these
discussions, nor what would be a better way of making design decisions, but
let's try to figure it out since this attempt has not worked out as expected
in my opinion.

[1] original discussion -
https://groups.google.com/forum/#!msg/foreman-dev/P9uRYV5K1Dc/xKMnzOOqDgAJ

--
Have a nice day,
Tomer Brisker
Red Hat Engineering

--
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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Re: [foreman-dev] Retire the RFC repo?

2017-03-13 Thread Daniel Lobato Garcia
On 03/13, Lukas Zapletal wrote:
> >some design decisions are still being made without going through the RFC 
> >process, either by mailing list discussions or by people just creating PRs 
> >without any prior discussion.
>
> I've seen this several times particularly in Smart Proxy repo where
> some design changes were part of regular PRs without proper
> discussion. To give an example, dependency injection framework was
> introduced as a Puppet 4 PR and this change turned things upside down
> in initialization phase. The sad thing about this one is I executed
> unit tests once for this change locally to see if it fixed random
> failures on my dev setup. Since the PR was entitled simply Puppet, I
> just made a comment without reading discussion or code. I am bringing
> it here because I think Smart Proxy (and larger plugins) are also
> subject for RFCs.
>
> I have a proposal, let's retire RFC github repo and simply fallback to
> mailing list but with [RFC] prefix so everyone is aware this is
> possible design change, refactoring or larger proposal that is at
> least worth reading. This should definitely not be annoying for anyone
> to at least inform about intentions, motivation, reasoning and overall
> design.
>
> I don't think we need any kind of design documents, but short
> description with a place for discussion before code is actually is
> written is a good thing to have.

+1. I became involved with PRs in the RFC repo at the beginning, but
eventually stopped as at least for me it's easier to discuss over proof
of concepts than merely docs.

I don't have strong feelings over one or another

>
> On Sun, Mar 12, 2017 at 9:52 AM, Tomer Brisker  wrote:
> > Hello,
> >
> > About a year ago, we decided to try using a new system for discussing design
> > decisions prior to making changes, by creating a repo for RFCs [1]. Part of
> > the problem was that when discussing on the mailing list, discussions tended
> > to die out without a resolution, and eventually whoever wrote the code made
> > the decision (or not).
> > Since then, there have been about 30 proposals made in the repository. 22 of
> > them are still open, most with no activity for months.
> > So I feel fairly safe to say that this change has not led to the wanted
> > result of getting decisions made faster or with more discussion. A
> > significant part of the proposals have less then 10 comments, in many cases
> > all from just one or two respondents. Eventually proposals are still decided
> > on only when someone goes ahead, writes the code and gets it merged.
> > This has also led to some discussions taking place without all of the
> > developers even knowing about them, as it would seem most don't follow that
> > repo regularly, leading to repeated discussions when a PR is created.
> > In addition, some design decisions are still being made without going
> > through the RFC process, either by mailing list discussions or by people
> > just creating PRs without any prior discussion.
> >
> > I'm not sure what we can do to increase peoples' involvement in these
> > discussions, nor what would be a better way of making design decisions, but
> > let's try to figure it out since this attempt has not worked out as expected
> > in my opinion.
> >
> > [1] original discussion -
> > https://groups.google.com/forum/#!msg/foreman-dev/P9uRYV5K1Dc/xKMnzOOqDgAJ
> >
> > --
> > Have a nice day,
> > Tomer Brisker
> > Red Hat Engineering
> >
> > --
> > 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+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Later,
>   Lukas @lzap Zapletal
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
Daniel Lobato Garcia

@dLobatog
blog.daniellobato.me
daniellobato.me

GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
Keybase: https://keybase.io/elobato

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature


Re: [foreman-dev] Retire the RFC repo?

2017-03-13 Thread Tomas Strachota
For me the biggest advantage of RFC repo over design discussions on
mailing list is that when you come back to it later, you immediately
see the latest state of the proposal without any need for reading
through the whole email thread. At the same time, when you what to see
the whole discussion you can display the outdated comments and older
commits. Sending/receiving comments in form of code reviews is quite
natural for me, but that's matter of personal preference.

In my opinion both described issues (RFCs not being closed and design
decisions without RFCs) aren't connected with github reviews but with
the process around. Moving back to mailing lists won't help us with
that. Therefore I'd keep RFC repo and rather work on defining how we
decide on accepting/rejecting RFCs and who's responsible for keeping
an eye on that.

T.

On Sun, Mar 12, 2017 at 9:52 AM, Tomer Brisker  wrote:
> Hello,
>
> About a year ago, we decided to try using a new system for discussing design
> decisions prior to making changes, by creating a repo for RFCs [1]. Part of
> the problem was that when discussing on the mailing list, discussions tended
> to die out without a resolution, and eventually whoever wrote the code made
> the decision (or not).
> Since then, there have been about 30 proposals made in the repository. 22 of
> them are still open, most with no activity for months.
> So I feel fairly safe to say that this change has not led to the wanted
> result of getting decisions made faster or with more discussion. A
> significant part of the proposals have less then 10 comments, in many cases
> all from just one or two respondents. Eventually proposals are still decided
> on only when someone goes ahead, writes the code and gets it merged.
> This has also led to some discussions taking place without all of the
> developers even knowing about them, as it would seem most don't follow that
> repo regularly, leading to repeated discussions when a PR is created.
> In addition, some design decisions are still being made without going
> through the RFC process, either by mailing list discussions or by people
> just creating PRs without any prior discussion.
>
> I'm not sure what we can do to increase peoples' involvement in these
> discussions, nor what would be a better way of making design decisions, but
> let's try to figure it out since this attempt has not worked out as expected
> in my opinion.
>
> [1] original discussion -
> https://groups.google.com/forum/#!msg/foreman-dev/P9uRYV5K1Dc/xKMnzOOqDgAJ
>
> --
> Have a nice day,
> Tomer Brisker
> Red Hat Engineering
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [foreman-dev] Retire the RFC repo?

2017-03-13 Thread Marek Hulán
On pondělí 13. března 2017 9:44:12 CET Lukas Zapletal wrote:
> >some design decisions are still being made without going through the RFC
> >process, either by mailing list discussions or by people just creating PRs
> >without any prior discussion.
> I've seen this several times particularly in Smart Proxy repo where
> some design changes were part of regular PRs without proper
> discussion. To give an example, dependency injection framework was
> introduced as a Puppet 4 PR and this change turned things upside down
> in initialization phase. The sad thing about this one is I executed
> unit tests once for this change locally to see if it fixed random
> failures on my dev setup. Since the PR was entitled simply Puppet, I
> just made a comment without reading discussion or code. I am bringing
> it here because I think Smart Proxy (and larger plugins) are also
> subject for RFCs.
> 
> I have a proposal, let's retire RFC github repo and simply fallback to
> mailing list but with [RFC] prefix so everyone is aware this is
> possible design change, refactoring or larger proposal that is at
> least worth reading. This should definitely not be annoying for anyone
> to at least inform about intentions, motivation, reasoning and overall
> design.

Works for me

> I don't think we need any kind of design documents, but short
> description with a place for discussion before code is actually is
> written is a good thing to have.

We can always fallback to pad/wiki/google docs/rfc repo when it's needed. Most 
of the time, it's not.

--
Marek

> 
> On Sun, Mar 12, 2017 at 9:52 AM, Tomer Brisker  wrote:
> > Hello,
> > 
> > About a year ago, we decided to try using a new system for discussing
> > design decisions prior to making changes, by creating a repo for RFCs
> > [1]. Part of the problem was that when discussing on the mailing list,
> > discussions tended to die out without a resolution, and eventually
> > whoever wrote the code made the decision (or not).
> > Since then, there have been about 30 proposals made in the repository. 22
> > of them are still open, most with no activity for months.
> > So I feel fairly safe to say that this change has not led to the wanted
> > result of getting decisions made faster or with more discussion. A
> > significant part of the proposals have less then 10 comments, in many
> > cases
> > all from just one or two respondents. Eventually proposals are still
> > decided on only when someone goes ahead, writes the code and gets it
> > merged. This has also led to some discussions taking place without all of
> > the developers even knowing about them, as it would seem most don't
> > follow that repo regularly, leading to repeated discussions when a PR is
> > created. In addition, some design decisions are still being made without
> > going through the RFC process, either by mailing list discussions or by
> > people just creating PRs without any prior discussion.
> > 
> > I'm not sure what we can do to increase peoples' involvement in these
> > discussions, nor what would be a better way of making design decisions,
> > but
> > let's try to figure it out since this attempt has not worked out as
> > expected in my opinion.
> > 
> > [1] original discussion -
> > https://groups.google.com/forum/#!msg/foreman-dev/P9uRYV5K1Dc/xKMnzOOqDgAJ
> > 
> > --
> > Have a nice day,
> > Tomer Brisker
> > Red Hat Engineering
> > 
> > --
> > 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [foreman-dev] Retire the RFC repo?

2017-03-13 Thread Lukas Zapletal
>some design decisions are still being made without going through the RFC 
>process, either by mailing list discussions or by people just creating PRs 
>without any prior discussion.

I've seen this several times particularly in Smart Proxy repo where
some design changes were part of regular PRs without proper
discussion. To give an example, dependency injection framework was
introduced as a Puppet 4 PR and this change turned things upside down
in initialization phase. The sad thing about this one is I executed
unit tests once for this change locally to see if it fixed random
failures on my dev setup. Since the PR was entitled simply Puppet, I
just made a comment without reading discussion or code. I am bringing
it here because I think Smart Proxy (and larger plugins) are also
subject for RFCs.

I have a proposal, let's retire RFC github repo and simply fallback to
mailing list but with [RFC] prefix so everyone is aware this is
possible design change, refactoring or larger proposal that is at
least worth reading. This should definitely not be annoying for anyone
to at least inform about intentions, motivation, reasoning and overall
design.

I don't think we need any kind of design documents, but short
description with a place for discussion before code is actually is
written is a good thing to have.

On Sun, Mar 12, 2017 at 9:52 AM, Tomer Brisker  wrote:
> Hello,
>
> About a year ago, we decided to try using a new system for discussing design
> decisions prior to making changes, by creating a repo for RFCs [1]. Part of
> the problem was that when discussing on the mailing list, discussions tended
> to die out without a resolution, and eventually whoever wrote the code made
> the decision (or not).
> Since then, there have been about 30 proposals made in the repository. 22 of
> them are still open, most with no activity for months.
> So I feel fairly safe to say that this change has not led to the wanted
> result of getting decisions made faster or with more discussion. A
> significant part of the proposals have less then 10 comments, in many cases
> all from just one or two respondents. Eventually proposals are still decided
> on only when someone goes ahead, writes the code and gets it merged.
> This has also led to some discussions taking place without all of the
> developers even knowing about them, as it would seem most don't follow that
> repo regularly, leading to repeated discussions when a PR is created.
> In addition, some design decisions are still being made without going
> through the RFC process, either by mailing list discussions or by people
> just creating PRs without any prior discussion.
>
> I'm not sure what we can do to increase peoples' involvement in these
> discussions, nor what would be a better way of making design decisions, but
> let's try to figure it out since this attempt has not worked out as expected
> in my opinion.
>
> [1] original discussion -
> https://groups.google.com/forum/#!msg/foreman-dev/P9uRYV5K1Dc/xKMnzOOqDgAJ
>
> --
> Have a nice day,
> Tomer Brisker
> Red Hat Engineering
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Later,
  Lukas @lzap Zapletal

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.