Date   
Docs guidance from other LFN projects

VM (Vicky) Brasseur
 

While at ONS last week I had the chance to meet with Sofia Wallin. She's worked with several of the other LFN projects to get their docs in shape and published.

 

She pointed me at some documentation that she and Thanh (now former Release Engineer for LF) put together to help other projects get started with publishing their documentation:

 

https://docs.releng.linuxfoundation.org/en/latest/project-documentation.html

 

She says that she's very happy to advise us and answer questions but seeing as how she's already working with several other projects she won't have the cycles to do more than that for us. Still, this will be a huge help!

 

--V

Re: 2019-04-03 Docs WG Meeting notes

VM (Vicky) Brasseur
 

Huge thanks for doing this, Kieran! The roundup of the current docs is particularly helpful. There are a few docs still on opencontrail.org which we'll need to get somehow represented in the TF world. I added a quick mention of that in the meeting notes.

 

As far as the Moving forward options, I'm strongly against the third one. While it would get us docs most quickly it also would be a big step backward in the TF-Juniper separation. The TF site already has a bunch of Juniper links, yeah, but those are slated for cleanup (at some point once alternatives exist, though I suppose they could simply be removed in the meantime?).

 

--V

 

From: "docs@..." <docs@...> on behalf of "kmilne via Lists.Tungsten.Io" <kmilne=juniper.net@...>
Reply-To: "docs@..." <docs@...>
Date: Wednesday, April 3, 2019 at 8:45 AM
To: "docs@..." <docs@...>
Subject: [TF docs] 2019-04-03 Docs WG Meeting notes

 

Hi folks,

Ended up just me on today's call. :)  I wrote up some minutes here, which are simply notes.. feel free to review and discuss here and/or we can pick up next week.

Cheers, Kieran 

Issue tracking for docs

VM (Vicky) Brasseur
 

We keep coming up with ideas for things to fix, but we're not yet doing a good job of tracking them.

 

While there are currently some issues in the tf/docs GitHub repo (because I didn't have anywhere else to put them; they'll be moved eventually), we don't seem to have any proper issue tracking for docs.

 

The rest of the project is using Jira. We should follow suit: https://jira.tungsten.io/projects/TFB/issues/

 

I've Cc'd pono for his advice on how to do this. Should we just add a 'documentation' label to the TFB bug tracking Jiras? Or have a subproject for docs? Or…?

 

--V

pono, could you please join next week's TF Docs call?

VM (Vicky) Brasseur
 

We want to talk about issue tracking. More info in the notes from yesterday's meeting:

 

https://wiki.tungsten.io/display/TUN/2019-04-10+Docs+WG+Meeting+notes

 

The Docs call is at 8:30AM Pacific Tim on Wednesday. Would you be able to join us?

 

--V

Updated Docs meeting wiki page

VM (Vicky) Brasseur
 

Here's the page: https://wiki.tungsten.io/display/TUN/Documentation+Project

 

Summary of changes…

 

  • Today I confirmed that Docs is a core project on TF so I changed the page name accordingly. Also: woo! Core project!
  • Added meeting schedule and connection info
  • Added the backlogged action items (stuff we can't get to yet for various reasons)

 

Enjoy.

 

--V

Re: pono, could you please join next week's TF Docs call?

VM (Vicky) Brasseur
 

Hey there, pono. Could you please let us know whether you'll be able to join the TF docs meeting next week?

 

--V

 

From: "docs@..." <docs@...> on behalf of "VM (Vicky) Brasseur via Lists.Tungsten.Io" <vmb=juniper.net@...>
Reply-To: "docs@..." <docs@...>
Date: Thursday, April 11, 2019 at 4:19 PM
To: "pono (Daniel Takamori)" <dtakamori@...>, "docs@..." <docs@...>
Subject: [TF docs] pono, could you please join next week's TF Docs call?

 

We want to talk about issue tracking. More info in the notes from yesterday's meeting:

 

https://wiki.tungsten.io/display/TUN/2019-04-10+Docs+WG+Meeting+notes

 

The Docs call is at 8:30AM Pacific Tim on Wednesday. Would you be able to join us?

 

--V

Re: pono, could you please join next week's TF Docs call?

Daniel Pono Takamori
 

Yes, I can make the call, see you then.

Cheers,
-Pono


On Thu, Apr 18, 2019 at 4:02 PM Vicky Brasseur <vmb@...> wrote:

Hey there, pono. Could you please let us know whether you'll be able to join the TF docs meeting next week?

 

--V

 

From: "docs@..." <docs@...> on behalf of "VM (Vicky) Brasseur via Lists.Tungsten.Io" <vmb=juniper.net@...>
Reply-To: "docs@..." <docs@...>
Date: Thursday, April 11, 2019 at 4:19 PM
To: "pono (Daniel Takamori)" <dtakamori@...>, "docs@..." <docs@...>
Subject: [TF docs] pono, could you please join next week's TF Docs call?

 

We want to talk about issue tracking. More info in the notes from yesterday's meeting:

 

https://wiki.tungsten.io/display/TUN/2019-04-10+Docs+WG+Meeting+notes

 

The Docs call is at 8:30AM Pacific Tim on Wednesday. Would you be able to join us?

 

--V

Please add agenda items for today's meeting

VM (Vicky) Brasseur
 

Here's the wiki page: https://wiki.tungsten.io/display/TUN/2019-04-24+Docs+Project+Meeting

 

After initial action item updates/announcements, we'll be leading off with pono, who's joining us to share information about Jira and issue tracking.

 

--V

NO CALL NEXT WEEK (May 1st)

VM (Vicky) Brasseur
 

Because most of the team is either in meetings or on PTO next week, we won't be having a docs call.

 

Casey, could you please remove it from the Community calendar for next week?

 

Thanks, all!

 

--V

JIRA 'docs' label

Daniel Pono Takamori
 

JIRA supports arbitrary labels for issues.  I just double checked that you can add a 'docs' or 'documentation' label to an issue and then that will be searchable to list all docs related issues.
If this is a sufficient solution we can leave it as is, but in the future you find you want more control/ workflows options for documentation related bugs we can reevaluate.

Cheers,
-Pono

Re: NO CALL NEXT WEEK (May 1st)

Casey Cain
 

Done.

Best,
Casey

On Wed, Apr 24, 2019 at 9:09 AM Vicky Brasseur <vmb@...> wrote:

Because most of the team is either in meetings or on PTO next week, we won't be having a docs call.

 

Casey, could you please remove it from the Community calendar for next week?

 

Thanks, all!

 

--V



--
Casey Cain
Technical Program Manager
Linux Foundation
_________________
IRC - CaseyLF
WeChat - okaru6

Re: NO CALL NEXT WEEK (May 1st)

VM (Vicky) Brasseur
 

Awesome, thanks!

 

From: "docs@..." <docs@...> on behalf of Casey Cain <ccain@...>
Reply-To: "docs@..." <docs@...>
Date: Wednesday, April 24, 2019 at 9:27 AM
To: Vicky Brasseur <vmb@...>
Cc: "docs@..." <docs@...>
Subject: Re: [TF docs] NO CALL NEXT WEEK (May 1st)

 

Done.

 

Best,

Casey

 

On Wed, Apr 24, 2019 at 9:09 AM Vicky Brasseur <vmb@...> wrote:

Because most of the team is either in meetings or on PTO next week, we won't be having a docs call.

 

Casey, could you please remove it from the Community calendar for next week?

 

Thanks, all!

 

--V


 

--

Casey Cain

Technical Program Manager

Linux Foundation

_________________

IRC - CaseyLF

WeChat - okaru6

Re: JIRA 'docs' label

VM (Vicky) Brasseur
 

Years of working with/for/around libraries and librarians have taught me that if you need to keep track of something for workflows, you do *not* want to have user-defined ontologies. If we use that then to filter out doc tickets we'll end up having to build a query that's "docs OR doc OR documentation OR dox OR documentation OR doc* OR…".

 

That way lies madness. ;-)

 

Instead, I suggest TF use Components. Currently we don't have any defined, but I'll be taking that up with the TSC after I send this email. There are some repo-related questions in there that will prevent the code side of TF from defining its components quickly, but Docs is more standalone thing and obviously is a separate component.

 

What do folks think of that? Shall the Docs team lead the way on imposing some sanity in the TF JIRA?

 

--V

 

 

From: "pono (Daniel Takamori)" <dtakamori@...>
Date: Wednesday, April 24, 2019 at 9:21 AM
To: "docs@..." <docs@...>
Cc: Vicky Brasseur <vmb@...>
Subject: JIRA 'docs' label

 

JIRA supports arbitrary labels for issues.  I just double checked that you can add a 'docs' or 'documentation' label to an issue and then that will be searchable to list all docs related issues.

If this is a sufficient solution we can leave it as is, but in the future you find you want more control/ workflows options for documentation related bugs we can reevaluate.

 

Cheers,

-Pono

Re: JIRA 'docs' label

Kieran Milne
 

I would generally agree that a touch more enforced structure (Components, etc.) would serve us well over the long term and keep sanity in check, etc.

 

Cheers, Kieran  

 

 

Juniper Internal

From: docs@... <docs@...> On Behalf Of VM (Vicky) Brasseur via Lists.Tungsten.Io
Sent: Wednesday, April 24, 2019 2:36 PM
To: Daniel Pono Takamori <dtakamori@...>; docs@...
Subject: Re: [TF docs] JIRA 'docs' label

 

Years of working with/for/around libraries and librarians have taught me that if you need to keep track of something for workflows, you do *not* want to have user-defined ontologies. If we use that then to filter out doc tickets we'll end up having to build a query that's "docs OR doc OR documentation OR dox OR documentation OR doc* OR…".

 

That way lies madness. ;-)

 

Instead, I suggest TF use Components. Currently we don't have any defined, but I'll be taking that up with the TSC after I send this email. There are some repo-related questions in there that will prevent the code side of TF from defining its components quickly, but Docs is more standalone thing and obviously is a separate component.

 

What do folks think of that? Shall the Docs team lead the way on imposing some sanity in the TF JIRA?

 

--V

 

 

From: "pono (Daniel Takamori)" <dtakamori@...>
Date: Wednesday, April 24, 2019 at 9:21 AM
To: "docs@..." <docs@...>
Cc: Vicky Brasseur <vmb@...>
Subject: JIRA 'docs' label

 

JIRA supports arbitrary labels for issues.  I just double checked that you can add a 'docs' or 'documentation' label to an issue and then that will be searchable to list all docs related issues.

If this is a sufficient solution we can leave it as is, but in the future you find you want more control/ workflows options for documentation related bugs we can reevaluate.

 

Cheers,

-Pono

Re: JIRA 'docs' label

Daniel Pono Takamori
 

Good idea!  I've added a 'Documentation' Component which can be set by users, but not misspelled :P


On Wed, Apr 24, 2019 at 1:56 PM Kieran Milne <kmilne@...> wrote:

I would generally agree that a touch more enforced structure (Components, etc.) would serve us well over the long term and keep sanity in check, etc.

 

Cheers, Kieran  

 

 

Juniper Internal

From: docs@... <docs@...> On Behalf Of VM (Vicky) Brasseur via Lists.Tungsten.Io
Sent: Wednesday, April 24, 2019 2:36 PM
To: Daniel Pono Takamori <dtakamori@...>; docs@...
Subject: Re: [TF docs] JIRA 'docs' label

 

Years of working with/for/around libraries and librarians have taught me that if you need to keep track of something for workflows, you do *not* want to have user-defined ontologies. If we use that then to filter out doc tickets we'll end up having to build a query that's "docs OR doc OR documentation OR dox OR documentation OR doc* OR…".

 

That way lies madness. ;-)

 

Instead, I suggest TF use Components. Currently we don't have any defined, but I'll be taking that up with the TSC after I send this email. There are some repo-related questions in there that will prevent the code side of TF from defining its components quickly, but Docs is more standalone thing and obviously is a separate component.

 

What do folks think of that? Shall the Docs team lead the way on imposing some sanity in the TF JIRA?

 

--V

 

 

From: "pono (Daniel Takamori)" <dtakamori@...>
Date: Wednesday, April 24, 2019 at 9:21 AM
To: "docs@..." <docs@...>
Cc: Vicky Brasseur <vmb@...>
Subject: JIRA 'docs' label

 

JIRA supports arbitrary labels for issues.  I just double checked that you can add a 'docs' or 'documentation' label to an issue and then that will be searchable to list all docs related issues.

If this is a sufficient solution we can leave it as is, but in the future you find you want more control/ workflows options for documentation related bugs we can reevaluate.

 

Cheers,

-Pono

Re: JIRA 'docs' label

VM (Vicky) Brasseur
 

Awesome. You rock, pono.

 

Will, you can open those docs tickets now. I'm looking forward to seeing them arrive. :-)

 

--V

 

From: "docs@..." <docs@...> on behalf of "pono (Daniel Takamori)" <dtakamori@...>
Reply-To: "docs@..." <docs@...>
Date: Thursday, April 25, 2019 at 9:03 AM
To: "docs@..." <docs@...>
Subject: Re: [TF docs] JIRA 'docs' label

 

Good idea!  I've added a 'Documentation' Component which can be set by users, but not misspelled :P

 

On Wed, Apr 24, 2019 at 1:56 PM Kieran Milne <kmilne@...> wrote:

I would generally agree that a touch more enforced structure (Components, etc.) would serve us well over the long term and keep sanity in check, etc.

 

Cheers, Kieran  

 

 

Juniper Internal

From: docs@... <docs@...> On Behalf Of VM (Vicky) Brasseur via Lists.Tungsten.Io
Sent: Wednesday, April 24, 2019 2:36 PM
To: Daniel Pono Takamori <dtakamori@...>; docs@...
Subject: Re: [TF docs] JIRA 'docs' label

 

Years of working with/for/around libraries and librarians have taught me that if you need to keep track of something for workflows, you do *not* want to have user-defined ontologies. If we use that then to filter out doc tickets we'll end up having to build a query that's "docs OR doc OR documentation OR dox OR documentation OR doc* OR…".

 

That way lies madness. ;-)

 

Instead, I suggest TF use Components. Currently we don't have any defined, but I'll be taking that up with the TSC after I send this email. There are some repo-related questions in there that will prevent the code side of TF from defining its components quickly, but Docs is more standalone thing and obviously is a separate component.

 

What do folks think of that? Shall the Docs team lead the way on imposing some sanity in the TF JIRA?

 

--V

 

 

From: "pono (Daniel Takamori)" <dtakamori@...>
Date: Wednesday, April 24, 2019 at 9:21 AM
To: "docs@..." <docs@...>
Cc: Vicky Brasseur <vmb@...>
Subject: JIRA 'docs' label

 

JIRA supports arbitrary labels for issues.  I just double checked that you can add a 'docs' or 'documentation' label to an issue and then that will be searchable to list all docs related issues.

If this is a sufficient solution we can leave it as is, but in the future you find you want more control/ workflows options for documentation related bugs we can reevaluate.

 

Cheers,

-Pono

Please add your agenda items for tomorrow's call

VM (Vicky) Brasseur
 

Re: New CLA Agreement

VM (Vicky) Brasseur
 

[+docs, since this conversation should be happening in the open]

 

For docs bugs, please open a ticket in the Tungsten Fabric Jira and select the Documentation component. I'm in the process of moving the docs issues from GitHub over to Jira, so please don't open an issue there. Launchpad is deprecated, so don't open a ticket there, either. =)

 

The docs assets, for the moment, are in the tungstenfabric/docs repository. Send a PR there for any changes and reference the Jira ticket. This process is in flux and will be moving to Gerrit, like all the other repos.

 

The CLA thing is a different matter and, I don't mind saying, it's highly irritating that it's still an open question. I'll open a separate thread for that one.

 

--V

 

From: Will Stevens <wstevens@...>
Date: Tuesday, May 7, 2019 at 11:34 AM
To: Casey Cain <ccain@...>
Cc: Sukhdev Kapur <sukhdev@...>, Vicky Brasseur <vmb@...>, "pono (Daniel Takamori)" <dtakamori@...>
Subject: Re: New CLA Agreement

 

I have opened a PR on the docs (https://review.opencontrail.org/#/c/51240/), I am not sure if it can be merged without me having a CLA registered in the system.  I am not sure how the CLA is linked to my LFID and my Ubuntu One accounts, so this is a bit of a black box for me.  It is still unclear to me what I am obligated to do as a 'contributor' to be able to actually contribute to the project (just the docs in this case).  I have successfully followed the steps to be able to create a PR, but now I am basically in a "what now" state.  There was no mention of the CLA in the documented process previously, but I assumed it had to be in play.  Also, there is no formal expectation set about what happens once you submit a PR.

 

I am trying to get through my TODOs and validating the documentation is one of them.  Given the current state of flux, how should we be handling the documentation assets?  It feels a bit like an impossible mission to review and verify our contributor documentation given the number of items in flight.  Who owns the documentation of the 'new' process which will be used once the transition gets underway?

 

Cheers,

 

Will Stevens

Chief Technology Officer

c 514.826.0190

 

 

 

On Tue, May 7, 2019 at 2:19 PM Casey Cain <ccain@...> wrote:

Hi, Will.  

 

I've put the appropriate people on the thread.  

We are currently still using review.opencontrail.org, true.  But we are actively migrating the repos to the LF Infrastructure.  This effort has recently started to pick up steam and I expect to be completed very soon.

Once it is, the automated CLA system which is now ready will be turned on.  Unfortunately until we are using the new repos, we have a manual system in place for the CLAs.  

We know that the migration will be done soon, but with no definitive date.  Because of this, we may need to manually process your CLA.

Are you currently being blocked from submitting any code?

 

Best,

Casey

 

On Tue, May 7, 2019 at 10:53 AM Will Stevens <wstevens@...> wrote:

Thanks Casey,

I am basically doing a bit of an audit of the documentation here (https://tungstenfabric.github.io/website#becoming-a-contributor) and here (https://github.com/Juniper/contrail-community-docs/blob/master/Contributor/GettingStarted/getting-started-with-opencontrail-development.md) to validate the process is clear and that it is possible to follow.

 

I would recommend you review the documented process here (https://review.opencontrail.org/#/settings/new-agreement) to ensure the instructions are valid (as they currently are not).

 

Additionally, I would like to ensure that CloudOps' CCLA is officially recognised and associated with my ID in Gerrit.

 

Please let me know how you would like me to update the documentation to account for the process.  This is the PR I currently have open for clarifying the process, which we may want to update: https://review.opencontrail.org/#/c/51240/

 

Cheers,

 

Will Stevens

Chief Technology Officer

c 514.826.0190

 

 

 

On Tue, May 7, 2019 at 1:46 PM Casey Cain <ccain@...> wrote:

Hi, Will.

Not only is Greg no longer with Juniper, but we've been migrating to an automated CLA process.

As manager@... doesn't have anything to do with this, let me start a new thread with you on this process.

 

Best,

Casey

 

On Tue, May 7, 2019 at 10:42 AM Will Stevens <wstevens@...> wrote:

Considering the fact that the mail bounced back for both the officially documented email addresses (gelkinbard@... & ci-admin@...) as per the documentation here (https://review.opencontrail.org/#/settings/new-agreement).  How should this be handled?  How should the completed CLAs be submitted?

 

Cheers,

 

Will Stevens

Chief Technology Officer

c 514.826.0190

 

 

 

On Tue, May 7, 2019 at 1:16 PM Will Stevens <wstevens@...> wrote:

Hey All,

This CCLA was submitted on June 28th, 2018, but it does not seem to have been processed.  

 

 

 

I am currently reviewing the contributor documentation to validate it is correct, which is why I am emailing all of you with this.  I think Casey is responsible for the CLAs from the LFN perspective, but I think Greg is likely the person to make sure the CCLA is associated with the user in Gerrit.

 

For your reference, I have a PR open to update the documentation to include the CLA signature as part of the documented process here: https://review.opencontrail.org/#/c/51240/

 

Let me know if I am missing anything or if you need any additional information from me.

 

My LFID is `swill`, my Gerrit username is also `swill` and I have two different emails associated with Gerrit (one of which is associated with my LFID).

 

Since I am reviewing the process, please let me know if I am missing anything.

 

Cheers,

 

Will Stevens

Chief Technology Officer

c 514.826.0190

 


 

--

Casey Cain

Technical Program Manager

Linux Foundation

_________________

IRC - CaseyLF

WeChat - okaru6


 

--

Casey Cain

Technical Program Manager

Linux Foundation

_________________

IRC - CaseyLF

WeChat - okaru6

Re: New CLA Agreement

Will Stevens
 

Alright.  I think I need dig into this a lot more.  I am having trouble figuring out how to manage the validation of the documentation given the current state of flux/transition in play.  Everything in the docs CURRENTLY point at the `opencontrail` repos, gerrit and the associated process.

There is a strange mix of the new Jira and the old Gerrit, which I have not yet tested in terms of integration of gating pull requests.  I have confirmed that Gerrit will refuse a PR without the appropriate ticket, but I have not yet confirmed which system is being referenced for that gating.

I have not reviewed the tungsten fabric docs repo yet because it was not referenced from the official documentation.  Instead, this one is referenced: https://github.com/Juniper/contrail-community-docs/blob/master/Contributor/GettingStarted/getting-started-with-opencontrail-development.md

I am going strictly on the docs and trying to follow/validate them and I don't actually know what the expected workflow and systems 'should' be in play.  I can dig into the tf docs repo and see where that leads me, but I am not sure if I am on a fools errand trying to validate/update the documentation if everything is going to change in a month (or whenever).

Thoughts?

Agreed, CLAs is a different, but related piece of this...

Will Stevens
Chief Technology Officer
c 514.826.0190



On Tue, May 7, 2019 at 2:57 PM Vicky Brasseur <vmb@...> wrote:

[+docs, since this conversation should be happening in the open]

 

For docs bugs, please open a ticket in the Tungsten Fabric Jira and select the Documentation component. I'm in the process of moving the docs issues from GitHub over to Jira, so please don't open an issue there. Launchpad is deprecated, so don't open a ticket there, either. =)

 

The docs assets, for the moment, are in the tungstenfabric/docs repository. Send a PR there for any changes and reference the Jira ticket. This process is in flux and will be moving to Gerrit, like all the other repos.

 

The CLA thing is a different matter and, I don't mind saying, it's highly irritating that it's still an open question. I'll open a separate thread for that one.

 

--V

 

From: Will Stevens <wstevens@...>
Date: Tuesday, May 7, 2019 at 11:34 AM
To: Casey Cain <ccain@...>
Cc: Sukhdev Kapur <sukhdev@...>, Vicky Brasseur <vmb@...>, "pono (Daniel Takamori)" <dtakamori@...>
Subject: Re: New CLA Agreement

 

I have opened a PR on the docs (https://review.opencontrail.org/#/c/51240/), I am not sure if it can be merged without me having a CLA registered in the system.  I am not sure how the CLA is linked to my LFID and my Ubuntu One accounts, so this is a bit of a black box for me.  It is still unclear to me what I am obligated to do as a 'contributor' to be able to actually contribute to the project (just the docs in this case).  I have successfully followed the steps to be able to create a PR, but now I am basically in a "what now" state.  There was no mention of the CLA in the documented process previously, but I assumed it had to be in play.  Also, there is no formal expectation set about what happens once you submit a PR.

 

I am trying to get through my TODOs and validating the documentation is one of them.  Given the current state of flux, how should we be handling the documentation assets?  It feels a bit like an impossible mission to review and verify our contributor documentation given the number of items in flight.  Who owns the documentation of the 'new' process which will be used once the transition gets underway?

 

Cheers,

 

Will Stevens

Chief Technology Officer

c 514.826.0190

 

Image removed by sender.

 

 

On Tue, May 7, 2019 at 2:19 PM Casey Cain <ccain@...> wrote:

Hi, Will.  

 

I've put the appropriate people on the thread.  

We are currently still using review.opencontrail.org, true.  But we are actively migrating the repos to the LF Infrastructure.  This effort has recently started to pick up steam and I expect to be completed very soon.

Once it is, the automated CLA system which is now ready will be turned on.  Unfortunately until we are using the new repos, we have a manual system in place for the CLAs.  

We know that the migration will be done soon, but with no definitive date.  Because of this, we may need to manually process your CLA.

Are you currently being blocked from submitting any code?

 

Best,

Casey

 

On Tue, May 7, 2019 at 10:53 AM Will Stevens <wstevens@...> wrote:

Thanks Casey,

I am basically doing a bit of an audit of the documentation here (https://tungstenfabric.github.io/website#becoming-a-contributor) and here (https://github.com/Juniper/contrail-community-docs/blob/master/Contributor/GettingStarted/getting-started-with-opencontrail-development.md) to validate the process is clear and that it is possible to follow.

 

I would recommend you review the documented process here (https://review.opencontrail.org/#/settings/new-agreement) to ensure the instructions are valid (as they currently are not).

 

Additionally, I would like to ensure that CloudOps' CCLA is officially recognised and associated with my ID in Gerrit.

 

Please let me know how you would like me to update the documentation to account for the process.  This is the PR I currently have open for clarifying the process, which we may want to update: https://review.opencontrail.org/#/c/51240/

 

Cheers,

 

Will Stevens

Chief Technology Officer

c 514.826.0190

 

Image removed by sender.

 

 

On Tue, May 7, 2019 at 1:46 PM Casey Cain <ccain@...> wrote:

Hi, Will.

Not only is Greg no longer with Juniper, but we've been migrating to an automated CLA process.

As manager@... doesn't have anything to do with this, let me start a new thread with you on this process.

 

Best,

Casey

 

On Tue, May 7, 2019 at 10:42 AM Will Stevens <wstevens@...> wrote:

Considering the fact that the mail bounced back for both the officially documented email addresses (gelkinbard@... & ci-admin@...) as per the documentation here (https://review.opencontrail.org/#/settings/new-agreement).  How should this be handled?  How should the completed CLAs be submitted?

 

Cheers,

 

Will Stevens

Chief Technology Officer

c 514.826.0190

 

Image removed by sender.

 

 

On Tue, May 7, 2019 at 1:16 PM Will Stevens <wstevens@...> wrote:

Hey All,

This CCLA was submitted on June 28th, 2018, but it does not seem to have been processed.  

 

 

 

I am currently reviewing the contributor documentation to validate it is correct, which is why I am emailing all of you with this.  I think Casey is responsible for the CLAs from the LFN perspective, but I think Greg is likely the person to make sure the CCLA is associated with the user in Gerrit.

 

For your reference, I have a PR open to update the documentation to include the CLA signature as part of the documented process here: https://review.opencontrail.org/#/c/51240/

 

Let me know if I am missing anything or if you need any additional information from me.

 

My LFID is `swill`, my Gerrit username is also `swill` and I have two different emails associated with Gerrit (one of which is associated with my LFID).

 

Since I am reviewing the process, please let me know if I am missing anything.

 

Cheers,

 

Will Stevens

Chief Technology Officer

c 514.826.0190

 

Image removed by sender.


 

--

Casey Cain

Technical Program Manager

Linux Foundation

_________________

IRC - CaseyLF

WeChat - okaru6


 

--

Casey Cain

Technical Program Manager

Linux Foundation

_________________

IRC - CaseyLF

WeChat - okaru6

Re: New CLA Agreement

VM (Vicky) Brasseur
 

"Fool's errand" isn't the right name for it, but I suspect "prematurely detailed" may be more accurate?

 

What's probably most useful right now is a census of all of the existing documentation. Once we know what's out there, we'll be in a position to start chipping away at it. Some of those docs may stay with their respective projects, others may get moved to the primary tf/docs repo. We also can take each one and figure out how it needs to be updated. It also would allow us to see what docs are missing, something I don't think we can do right now.

 

Right now, from what I can tell, we don't even have a good sense of what docs exist. That would be a very good place to start and doing that census would be invaluable.

 

What do you think?

 

--V

 

From: Will Stevens <wstevens@...>
Date: Tuesday, May 7, 2019 at 2:59 PM
To: Vicky Brasseur <vmb@...>
Cc: Casey Cain <ccain@...>, Sukhdev Kapur <sukhdev@...>, "pono (Daniel Takamori)" <dtakamori@...>, "docs@..." <docs@...>
Subject: Re: New CLA Agreement

 

Alright.  I think I need dig into this a lot more.  I am having trouble figuring out how to manage the validation of the documentation given the current state of flux/transition in play.  Everything in the docs CURRENTLY point at the `opencontrail` repos, gerrit and the associated process.

 

There is a strange mix of the new Jira and the old Gerrit, which I have not yet tested in terms of integration of gating pull requests.  I have confirmed that Gerrit will refuse a PR without the appropriate ticket, but I have not yet confirmed which system is being referenced for that gating.

 

I have not reviewed the tungsten fabric docs repo yet because it was not referenced from the official documentation.  Instead, this one is referenced: https://github.com/Juniper/contrail-community-docs/blob/master/Contributor/GettingStarted/getting-started-with-opencontrail-development.md

 

I am going strictly on the docs and trying to follow/validate them and I don't actually know what the expected workflow and systems 'should' be in play.  I can dig into the tf docs repo and see where that leads me, but I am not sure if I am on a fools errand trying to validate/update the documentation if everything is going to change in a month (or whenever).

 

Thoughts?

 

Agreed, CLAs is a different, but related piece of this...

 

Will Stevens

Chief Technology Officer

c 514.826.0190

 

 

 

On Tue, May 7, 2019 at 2:57 PM Vicky Brasseur <vmb@...> wrote:

[+docs, since this conversation should be happening in the open]

 

For docs bugs, please open a ticket in the Tungsten Fabric Jira and select the Documentation component. I'm in the process of moving the docs issues from GitHub over to Jira, so please don't open an issue there. Launchpad is deprecated, so don't open a ticket there, either. =)

 

The docs assets, for the moment, are in the tungstenfabric/docs repository. Send a PR there for any changes and reference the Jira ticket. This process is in flux and will be moving to Gerrit, like all the other repos.

 

The CLA thing is a different matter and, I don't mind saying, it's highly irritating that it's still an open question. I'll open a separate thread for that one.

 

--V

 

From: Will Stevens <wstevens@...>
Date: Tuesday, May 7, 2019 at 11:34 AM
To: Casey Cain <ccain@...>
Cc: Sukhdev Kapur <sukhdev@...>, Vicky Brasseur <vmb@...>, "pono (Daniel Takamori)" <dtakamori@...>
Subject: Re: New CLA Agreement

 

I have opened a PR on the docs (https://review.opencontrail.org/#/c/51240/), I am not sure if it can be merged without me having a CLA registered in the system.  I am not sure how the CLA is linked to my LFID and my Ubuntu One accounts, so this is a bit of a black box for me.  It is still unclear to me what I am obligated to do as a 'contributor' to be able to actually contribute to the project (just the docs in this case).  I have successfully followed the steps to be able to create a PR, but now I am basically in a "what now" state.  There was no mention of the CLA in the documented process previously, but I assumed it had to be in play.  Also, there is no formal expectation set about what happens once you submit a PR.

 

I am trying to get through my TODOs and validating the documentation is one of them.  Given the current state of flux, how should we be handling the documentation assets?  It feels a bit like an impossible mission to review and verify our contributor documentation given the number of items in flight.  Who owns the documentation of the 'new' process which will be used once the transition gets underway?

 

Cheers,

 

Will Stevens

Chief Technology Officer

c 514.826.0190

 

 

 

On Tue, May 7, 2019 at 2:19 PM Casey Cain <ccain@...> wrote:

Hi, Will.  

 

I've put the appropriate people on the thread.  

We are currently still using review.opencontrail.org, true.  But we are actively migrating the repos to the LF Infrastructure.  This effort has recently started to pick up steam and I expect to be completed very soon.

Once it is, the automated CLA system which is now ready will be turned on.  Unfortunately until we are using the new repos, we have a manual system in place for the CLAs.  

We know that the migration will be done soon, but with no definitive date.  Because of this, we may need to manually process your CLA.

Are you currently being blocked from submitting any code?

 

Best,

Casey

 

On Tue, May 7, 2019 at 10:53 AM Will Stevens <wstevens@...> wrote:

Thanks Casey,

I am basically doing a bit of an audit of the documentation here (https://tungstenfabric.github.io/website#becoming-a-contributor) and here (https://github.com/Juniper/contrail-community-docs/blob/master/Contributor/GettingStarted/getting-started-with-opencontrail-development.md) to validate the process is clear and that it is possible to follow.

 

I would recommend you review the documented process here (https://review.opencontrail.org/#/settings/new-agreement) to ensure the instructions are valid (as they currently are not).

 

Additionally, I would like to ensure that CloudOps' CCLA is officially recognised and associated with my ID in Gerrit.

 

Please let me know how you would like me to update the documentation to account for the process.  This is the PR I currently have open for clarifying the process, which we may want to update: https://review.opencontrail.org/#/c/51240/

 

Cheers,

 

Will Stevens

Chief Technology Officer

c 514.826.0190

 

 

 

On Tue, May 7, 2019 at 1:46 PM Casey Cain <ccain@...> wrote:

Hi, Will.

Not only is Greg no longer with Juniper, but we've been migrating to an automated CLA process.

As manager@... doesn't have anything to do with this, let me start a new thread with you on this process.

 

Best,

Casey

 

On Tue, May 7, 2019 at 10:42 AM Will Stevens <wstevens@...> wrote:

Considering the fact that the mail bounced back for both the officially documented email addresses (gelkinbard@... & ci-admin@...) as per the documentation here (https://review.opencontrail.org/#/settings/new-agreement).  How should this be handled?  How should the completed CLAs be submitted?

 

Cheers,

 

Will Stevens

Chief Technology Officer

c 514.826.0190

 

 

 

On Tue, May 7, 2019 at 1:16 PM Will Stevens <wstevens@...> wrote:

Hey All,

This CCLA was submitted on June 28th, 2018, but it does not seem to have been processed.  

 

 

 

I am currently reviewing the contributor documentation to validate it is correct, which is why I am emailing all of you with this.  I think Casey is responsible for the CLAs from the LFN perspective, but I think Greg is likely the person to make sure the CCLA is associated with the user in Gerrit.

 

For your reference, I have a PR open to update the documentation to include the CLA signature as part of the documented process here: https://review.opencontrail.org/#/c/51240/

 

Let me know if I am missing anything or if you need any additional information from me.

 

My LFID is `swill`, my Gerrit username is also `swill` and I have two different emails associated with Gerrit (one of which is associated with my LFID).

 

Since I am reviewing the process, please let me know if I am missing anything.

 

Cheers,

 

Will Stevens

Chief Technology Officer

c 514.826.0190

 


 

--

Casey Cain

Technical Program Manager

Linux Foundation

_________________

IRC - CaseyLF

WeChat - okaru6


 

--

Casey Cain

Technical Program Manager

Linux Foundation

_________________

IRC - CaseyLF

WeChat - okaru6