[RFC] Deprecate and move Github RFC repo content

Hey,

this is another proposal to deprecate Github RFC repo and move the
content to our wiki. Reasons:

A) There is zero merged proposals for the past year (Jan-Nov 2017):

B) Activity is very low (comments in 3 PRs last winter, 3 PRs last
summer, 1 PR last month):
https://github.com/theforeman/rfcs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc

C) There is only one published RFC on the front page (by the way I am
the author). I see some randomly numbered files in text/ folder but
this does not look like a friendly space to newcomers or even
experienced guys. We failed following processes described on the front
page obviously and it's no surprise - people in need of writing a
proposal need to focus on the most important stuff.

D) Developers naturally create [RFC] threads on our -dev list, some
random subjects:

  • Make foreman STI to work even when an inherited class is not found
  • Proxies with multiple interfaces
  • Found In Version Katello Redmine custom field
  • Foreman with Puppet in a wildcard domain leads to nodes mistaken identity
  • Templates rendering only through Proxies
    … and others I am gonna stop here. These are e-mail from core devs
    and also our community.

E) It's been already proposed on list by Tomer ("Retire the RFC
repo"). Some people expressed intentions to use it (Justin, Eric, John
and Perry) but I haven't seen much activity (see above). One of the
reasons was time, but these days we should be pushing hard on
proposals for the next generation of Foreman versions and I don't see
this. Greg agreed this needs some more work around visibility and
process improvement, but I don't see much improvements.

F) Content is not visible, most of us don't use it and WIP RFCs are
quite unreadable. I want to read proposal as a completed document and
then I want to send a consistent opinion about it.

PROPOSAL

Let's close the RFC repo for new PRs, add a note that contents has
been moved. I will then move all finished RFCs to our wiki page. We
already have that for years, it's named Features:

http://projects.theforeman.org/projects/foreman/wiki/Features

There is a template

http://projects.theforeman.org/projects/foreman/wiki/Sprint_Feature_Template

And couple of proposals already:

http://projects.theforeman.org/projects/foreman/wiki/Pagelets
http://projects.theforeman.org/projects/foreman/wiki/Discovered_host_redesign
http://projects.theforeman.org/projects/foreman/wiki/Remote_Execution_Design
http://projects.theforeman.org/projects/foreman/wiki/CentralizedLogging
http://projects.theforeman.org/projects/foreman/wiki/PXE_Booting_UEFI
(I moved this one, I take this back)

The wiki pages are just a place to put content on, a opt-in way. Most
of us will likely prefer e-mail list for smaller proposals and I
encourage everybody to continue to do so. This is just a complementary
place, but it's not pulling conversation out of our devel list.

BENEFITS

  1. Stops splitting place for important discussions - we already have
    the dev list.
  2. Actually readable content, easy to edit, easy to track changes.
  3. Rich content - github hasn't invented HTML/RTF with images, wiki
    can do it all.
  4. Free form - just write your proposal, add a title, name and status
    and that's it.

ALTERNATIVE PROPOSAL

Let's keep the github repo but remove all git content and move all
pages to wiki section under that github repository. Discussion will be
made in the devel mailing list. Advantage is that the syntax will
remain the same, but I hereby offer migration of all finished RFCs
into RedMine syntax.

··· -- Later, Lukas @lzap Zapletal

Since you volunteered to clean up, definitely a +1 from me :slight_smile:

I agree that discussion should happen outside of the RFC itself as the
discussion in the PR was usually hard to follow. It was not clear if comments
are still valid or not. Mail list seems to have good presence of developers so
I expect the discussion to happen there. I don't really care which wiki we use
for writing summaries of this discussion but redmine feels a bit more natural
to me.

··· -- Marek

On středa 15. listopadu 2017 10:14:49 CET Lukas Zapletal wrote:

Hey,

this is another proposal to deprecate Github RFC repo and move the
content to our wiki. Reasons:

A) There is zero merged proposals for the past year (Jan-Nov 2017):
Commits · theforeman/rfcs · GitHub

B) Activity is very low (comments in 3 PRs last winter, 3 PRs last
summer, 1 PR last month):
Pull requests · theforeman/rfcs · GitHub> desc

C) There is only one published RFC on the front page (by the way I am
the author). I see some randomly numbered files in text/ folder but
this does not look like a friendly space to newcomers or even
experienced guys. We failed following processes described on the front
page obviously and it’s no surprise - people in need of writing a
proposal need to focus on the most important stuff.

D) Developers naturally create [RFC] threads on our -dev list, some
random subjects:

  • Make foreman STI to work even when an inherited class is not found
  • Proxies with multiple interfaces
  • Found In Version Katello Redmine custom field
  • Foreman with Puppet in a wildcard domain leads to nodes mistaken identity
  • Templates rendering only through Proxies
    … and others I am gonna stop here. These are e-mail from core devs
    and also our community.

E) It’s been already proposed on list by Tomer (“Retire the RFC
repo”). Some people expressed intentions to use it (Justin, Eric, John
and Perry) but I haven’t seen much activity (see above). One of the
reasons was time, but these days we should be pushing hard on
proposals for the next generation of Foreman versions and I don’t see
this. Greg agreed this needs some more work around visibility and
process improvement, but I don’t see much improvements.

F) Content is not visible, most of us don’t use it and WIP RFCs are
quite unreadable. I want to read proposal as a completed document and
then I want to send a consistent opinion about it.

PROPOSAL

Let’s close the RFC repo for new PRs, add a note that contents has
been moved. I will then move all finished RFCs to our wiki page. We
already have that for years, it’s named Features:

http://projects.theforeman.org/projects/foreman/wiki/Features

There is a template

http://projects.theforeman.org/projects/foreman/wiki/Sprint_Feature_Template

And couple of proposals already:

http://projects.theforeman.org/projects/foreman/wiki/Pagelets
http://projects.theforeman.org/projects/foreman/wiki/Discovered_host_redesig
n
http://projects.theforeman.org/projects/foreman/wiki/Remote_Execution_Desig
n http://projects.theforeman.org/projects/foreman/wiki/CentralizedLogging
http://projects.theforeman.org/projects/foreman/wiki/PXE_Booting_UEFI (I
moved this one, I take this back)

The wiki pages are just a place to put content on, a opt-in way. Most
of us will likely prefer e-mail list for smaller proposals and I
encourage everybody to continue to do so. This is just a complementary
place, but it’s not pulling conversation out of our devel list.

BENEFITS

  1. Stops splitting place for important discussions - we already have
    the dev list.
  2. Actually readable content, easy to edit, easy to track changes.
  3. Rich content - github hasn’t invented HTML/RTF with images, wiki
    can do it all.
  4. Free form - just write your proposal, add a title, name and status
    and that’s it.

ALTERNATIVE PROPOSAL

Let’s keep the github repo but remove all git content and move all
pages to wiki section under that github repository. Discussion will be
made in the devel mailing list. Advantage is that the syntax will
remain the same, but I hereby offer migration of all finished RFCs
into RedMine syntax.

Yea +1 from me too. I think the biggest problem was that merging them has
no direct link to the issue or PRs that resolved a RFC, this meant the
author or someone had to remember to go back, ping someone to merge which
often didn't happen. Whereas with a mailing list its okay to leave a thread
untouched that doesn't necessarily require any "closing" step.

Without wanting to hijack this thread… I think this is actually one of
the areas Discourse can benefit us, generally as a community I think were
not very good at making a decision after a discussion. I think some of the
features it seems to provide (voting system) could help with that.

··· On Wed, Nov 15, 2017 at 10:08 AM, Marek Hulán wrote:

Since you volunteered to clean up, definitely a +1 from me :slight_smile:

I agree that discussion should happen outside of the RFC itself as the
discussion in the PR was usually hard to follow. It was not clear if
comments
are still valid or not. Mail list seems to have good presence of
developers so
I expect the discussion to happen there. I don’t really care which wiki we
use
for writing summaries of this discussion but redmine feels a bit more
natural
to me.


Marek

On středa 15. listopadu 2017 10:14:49 CET Lukas Zapletal wrote:

Hey,

this is another proposal to deprecate Github RFC repo and move the
content to our wiki. Reasons:

A) There is zero merged proposals for the past year (Jan-Nov 2017):
Commits · theforeman/rfcs · GitHub

B) Activity is very low (comments in 3 PRs last winter, 3 PRs last
summer, 1 PR last month):
Pull requests · theforeman/rfcs · GitHub
3Aopen+sort%3Aupdated-> desc

C) There is only one published RFC on the front page (by the way I am
the author). I see some randomly numbered files in text/ folder but
this does not look like a friendly space to newcomers or even
experienced guys. We failed following processes described on the front
page obviously and it’s no surprise - people in need of writing a
proposal need to focus on the most important stuff.

D) Developers naturally create [RFC] threads on our -dev list, some
random subjects:

  • Make foreman STI to work even when an inherited class is not found
  • Proxies with multiple interfaces
  • Found In Version Katello Redmine custom field
  • Foreman with Puppet in a wildcard domain leads to nodes mistaken
    identity
  • Templates rendering only through Proxies
    … and others I am gonna stop here. These are e-mail from core devs
    and also our community.

E) It’s been already proposed on list by Tomer (“Retire the RFC
repo”). Some people expressed intentions to use it (Justin, Eric, John
and Perry) but I haven’t seen much activity (see above). One of the
reasons was time, but these days we should be pushing hard on
proposals for the next generation of Foreman versions and I don’t see
this. Greg agreed this needs some more work around visibility and
process improvement, but I don’t see much improvements.

F) Content is not visible, most of us don’t use it and WIP RFCs are
quite unreadable. I want to read proposal as a completed document and
then I want to send a consistent opinion about it.

PROPOSAL

Let’s close the RFC repo for new PRs, add a note that contents has
been moved. I will then move all finished RFCs to our wiki page. We
already have that for years, it’s named Features:

http://projects.theforeman.org/projects/foreman/wiki/Features

There is a template

About - Foreman
Sprint_Feature_Template

And couple of proposals already:

http://projects.theforeman.org/projects/foreman/wiki/Pagelets
About - Foreman
Discovered_host_redesig
n
About - Foreman
Remote_Execution_Desig
n About - Foreman
CentralizedLogging
http://projects.theforeman.org/projects/foreman/wiki/PXE_Booting_UEFI (I
moved this one, I take this back)

The wiki pages are just a place to put content on, a opt-in way. Most
of us will likely prefer e-mail list for smaller proposals and I
encourage everybody to continue to do so. This is just a complementary
place, but it’s not pulling conversation out of our devel list.

BENEFITS

  1. Stops splitting place for important discussions - we already have
    the dev list.
  2. Actually readable content, easy to edit, easy to track changes.
  3. Rich content - github hasn’t invented HTML/RTF with images, wiki
    can do it all.
  4. Free form - just write your proposal, add a title, name and status
    and that’s it.

ALTERNATIVE PROPOSAL

Let’s keep the github repo but remove all git content and move all
pages to wiki section under that github repository. Discussion will be
made in the devel mailing list. Advantage is that the syntax will
remain the same, but I hereby offer migration of all finished RFCs
into RedMine syntax.


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 to moving them to the Redmine wiki. The RFC repo was a good
experiment but handled badly (at least some of the blame for that is on
me). At this point I don't think it's possible to rescue it.

··· On 15/11/17 10:52, Sean O'Keeffe wrote: > Without wanting to hijack this thread... I think this is actually one of > the areas Discourse can benefit us, generally as a community I think were > not very good at making a decision after a discussion. I think some of the > features it seems to provide (voting system) could help with that.

Clearly I’m going to +1 that comment too :wink: - the other really useful
thing is the per-thread analytics you can get about views, top links, etc.

Greg

Since I already suggested this some months ago, obvious +1 from me :slight_smile:

··· On Wed, Nov 15, 2017 at 1:41 PM, Greg Sutcliffe wrote: > +1 to moving them to the Redmine wiki. The RFC repo was a good > experiment but handled badly (at least some of the blame for that is on > me). At this point I don't think it's possible to rescue it. > > On 15/11/17 10:52, Sean O'Keeffe wrote: >> Without wanting to hijack this thread... I think this is actually one of >> the areas Discourse can benefit us, generally as a community I think were >> not very good at making a decision after a discussion. I think some of the >> features it seems to provide (voting system) could help with that. > > Clearly I'm going to +1 that comment too ;) - the other really useful > thing is the per-thread analytics you can get about views, top links, etc. > > 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+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/d/optout.


Have a nice day,
Tomer Brisker
Red Hat Engineering

Since I already suggested this some months ago, obvious +1 from me :)

+1 to moving them to the Redmine wiki. The RFC repo was a good
experiment but handled badly (at least some of the blame for that is on
me). At this point I don't think it's possible to rescue it.

Without wanting to hijack this thread... I think this is actually one of
the areas Discourse can benefit us, generally as a community I think were
not very good at making a decision after a discussion. I think some of the
features it seems to provide (voting system) could help with that.

Clearly I'm going to +1 that comment too ;) - the other really useful
thing is the per-thread analytics you can get about views, top links, etc.

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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
If it helps, I think
https://github.com/blog/2471-introducing-team-discussions looks also like a good tool for these kind of discussions, without any need for a moderator. The discussions are restricted to people in the GitHub team.

··· On 11/15, Tomer Brisker wrote:
On Wed, Nov 15, 2017 at 1:41 PM, Greg Sutcliffe <greg@emeraldreverie.org> wrote:
On 15/11/17 10:52, Sean O'Keeffe wrote:


--
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+unsubscribe@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
Yeah, I also think this would make sense. It's basically a wiki with discussion - ideal.

Greg, can you turn it on in RFC repo so we can test this? If this fails, we can move to wiki and deprecate that repo.


··· --

LZ
  Lukas @lzap Zapletal
If it helps, I think
https://github.com/blog/2471-introducing-team-discussions looks also
like a good tool for these kind of discussions, without any need for
a moderator. The discussions are restricted to people in the GitHub
team.
TLDR: -1 to this from me, I'm afraid. Let me explain.

Firstly, we have to ask if this is a *replacement* for other discussions (i.e. dev-list), which I don't think you're proposing, or in-addition-to dev-list. I'll cover both, just to be complete.

If it's an *additional* channel, then it will die. This is exactly what happened to the RFC repo the first time - we added an extra place to discuss things, the discussion fragmented, and then the network effect dragged all the discussion back to the dev-list.

In addition, it's *even* more fragmented than the RFC repo, because it's per-team - and we have 63 teams. Yes, there's a "members" team, but even that only has 56 people in it (the org has 71, so something is out of line there). Limiting discussion to a single team means many more places to check if you want to know what's being discussed (but aren't already a part of the discussion).

It's also worse than RFC repo in the sense that it still requires a GitHub account to participate - but now you *also* have to be in the team too. It does respect team structure, but we don't currently nest teams, and propagating discussions between child teams (eg plugins) looks awkward. That means we get into small, silo'ed discussions that don't get enough feedback from the wider community. That's dangerous echo-chamber / groupthink ground.

On the other hand, if it's a *replacement* for dev-list (bear with me here :P), then I don't see anything here which is better than the *other* replacement for dev-list on the table (that's Discourse, which may happen looking at the current poll). There we *centralise* the discussion instead of fragmenting it, but keep the wiki-like powers, can use @group notifications to alert people, and users can join in too if they wish. As a *replacement*, team discussions thus feels inferior.

Either way, I'm not a fan. This is a case of knowing the purpose of your communication channels and picking *one* way to handle it that suits the purpose. Having >1 just fragments everything (I learned that the hard way with the RFC repo, sadly). At the very least, I'd ask that we finish sorting out Discourse before we start on "communication changes, round 2" - we may find the new tooling should be part of that process.

··· On 29/11/17 08:47, Daniel Lobato Garcia wrote:

On 29/11/17 08:55, Lukas Zapletal wrote:

Greg, can you turn it on in RFC repo so we can test this? If this
fails, we can move to wiki and deprecate that repo.
It's not per repo, it's per team, and GitHub has already enabled it across the entire site. It can't be disabled as far as I can see, so you can try it in any team you're a member of.

example: https://github.com/orgs/theforeman/teams/discovery/discussions

Greg
Yeah I think I misinterpreted how this feature works. I thought its just a discussion per project. This is per team I guess, as you pointed out.

Ok I am migrating back to wiki unless there is some blocker raised.

LZ


··· On Wed, Nov 29, 2017 at 11:37 AM, Greg Sutcliffe <greg@emeraldreverie.org> wrote:
On 29/11/17 08:47, Daniel Lobato Garcia wrote:
If it helps, I think
https://github.com/blog/2471-introducing-team-discussions looks also
like a good tool for these kind of discussions, without any need for
a moderator. The discussions are restricted to people in the GitHub
team.

TLDR: -1 to this from me, I'm afraid. Let me explain.

Firstly, we have to ask if this is a *replacement* for other
discussions (i.e. dev-list), which I don't think you're proposing, or
in-addition-to dev-list. I'll cover both, just to be complete.

If it's an *additional* channel, then it will die. This is exactly what
happened to the RFC repo the first time - we added an extra place to
discuss things, the discussion fragmented, and then the network effect
dragged all the discussion back to the dev-list.

In addition, it's *even* more fragmented than the RFC repo, because it's
per-team - and we have 63 teams. Yes, there's a "members" team, but even
that only has 56 people in it (the org has 71, so something is out of
line there). Limiting discussion to a single team means many more places
to check if you want to know what's being discussed (but aren't already
a part of the discussion).

It's also worse than RFC repo in the sense that it still requires a
GitHub account to participate - but now you *also* have to be in the
team too. It does respect team structure, but we don't currently nest
teams, and propagating discussions between child teams (eg plugins)
looks awkward. That means we get into small, silo'ed discussions that
don't get enough feedback from the wider community. That's dangerous
echo-chamber / groupthink ground.

On the other hand, if it's a *replacement* for dev-list (bear with me
here :P), then I don't see anything here which is better than the
*other* replacement for dev-list on the table (that's Discourse, which
may happen looking at the current poll). There we *centralise* the
discussion instead of fragmenting it, but keep the wiki-like powers, can
use @group notifications to alert people, and users can join in too if
they wish. As a *replacement*, team discussions thus feels inferior.

Either way, I'm not a fan. This is a case of knowing the purpose of your
communication channels and picking *one* way to handle it that suits the
purpose. Having >1 just fragments everything (I learned that the hard
way with the RFC repo, sadly). At the very least, I'd ask that we finish
sorting out Discourse before we start on "communication changes, round
2" - we may find the new tooling should be part of that process.

On 29/11/17 08:55, Lukas Zapletal wrote:

Greg, can you turn it on in RFC repo so we can test this? If this
fails, we can move to wiki and deprecate that repo.

It's not per repo, it's per team, and GitHub has already enabled it
across the entire site. It can't be disabled as far as I can see, so you
can try it in any team you're a member of.

example: https://github.com/orgs/theforeman/teams/discovery/discussions

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


--
Later,
  Lukas @lzap Zapletal