Re: [DISCUSSION] Workshop idea

[Cédrick Lunven]

Hi all,

Patrick beat me on this but yes, at Datastax, we do have a platform ready
for those.

We are running virtual workshops twice a week discussing Cassandra, here is
the playlist

   - 8 weeks program:
   
https://www.youtube.com/watch?v=VW8C3nU0EzQ&list=PL2g2h-wyI4SpspPamyuinj9sgxjTFn9ex
   - standalone topics :
   https://www.youtube.com/playlist?list=PL2g2h-wyI4SqcSXuShseNQnHMAWl0SF4q

Anyone could be there only skype is required as a speaker and we handle the
rest.

   - Live demos and hands using what you like Docker, katacoda, Gitpod,
   - Interaction with people in the youtube chat but also the community
   discord room:* The Fellowship of the rings (*INVITE=>
   https://bit.ly/cassandra-workshop
   

   )
   -
   - Live questions/polling to the audience using mentimenter (tell us the
   question you want)

Well, happy to host any initiative.
Cedrick




On Fri, Jul 31, 2020 at 2:37 AM Patrick McFadin  wrote:

> The developer relations team at DataStax has a pretty cool workshop setup
> going with Twitch and YouTube we could volunteer for this effort. I think a
> 4.0 workshop with Ekaterina and Carlos would be amazing! You just need
> Skype and some content and we can handle the rest.
>
> Patrick
>
> On Wed, Jul 29, 2020 at 4:36 PM Ekaterina Dimitrova  >
> wrote:
>
> > +1 on this; would be great to make a demo to show our users the upgrade
> > process, I think
> >
> > On Tue, 28 Jul 2020 at 13:54, Carlos Rolo  wrote:
> >
> > > I would love this idea!
> > > I'm currently working on upgrading cluster to 4.0 (testing) and if
> > needed I
> > > can talk about that.
> > >
> > > [image: Pythian]
> > > *Carlos Rolo* | Big Data Consultant | [image: LinkedIn]
> > > <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_in_carlosjuzarterolo_&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=CRDTby7ZKMKOJuR7qj8hGNHMqiMtY_3sbc8FBSZtTdo&m=Bc64psBqdGKXYwy75FuWv2yGdQApNbWpcNhRitOwyXE&s=Fk7clXJGmf0SAn2NJ5KRce5QVRuVIV26nEyWT-nHT_4&e=
> >
> > > *m* +351 918 918 100
> > > r...@pythian.com   *www.pythian.com*
> > > <
> > >
> >
> https://www.google.com/url?q=https%3A%2F%2Fwww.pythian.com&sa=D&sntz=1&usg=AFQjCNHhR4YJfBb19QxglicHut6aTAjXyQ
> > > >
> > > [image: Pythian]
> > > <
> > >
> >
> https://www.google.com/url?q=https%3A%2F%2Fwww.pythian.com%2Femail-footer-click&sa=D&sntz=1&usg=AFQjCNF7Ld7zJGpBUtvj3Lum--bqwUvvog
> > > >
> > >
> > >
> > > On Tue, Jul 28, 2020 at 5:36 PM Charles Cao 
> > wrote:
> > >
> > > > +1. Great idea. A virtual meetup, Introduction to Cassandra 4.0, will
> > > > help users try and test 4.0.
> > > >
> > > > ~Charles
> > > >
> > > > On Tue, Jul 28, 2020 at 9:26 AM Ekaterina Dimitrova
> > > >  wrote:
> > > > >
> > > > > Hi Nate, all,
> > > > > I was thinking about a 1 hour online talk on 4.0, new features,
> > > testing,
> > > > etc. I guess it can be also recorded and distributed for those who
> > missed
> > > > the live session. Slides also could be added to slide share.
> > > > > As you mentioned demos, that sounds good to me if people have the
> > time
> > > > for demos to be recorded and distributed.
> > > > >
> > > > > Best regards,
> > > > > Ekaterina
> > > > >
> > > > > > On 27 Jul 2020, at 21:29, Nate McCall 
> wrote:
> > > > > >
> > > > > > This is a really interesting idea, particularly given that at
> this
> > > > point in
> > > > > > our release cycle previously, there would be demos/roadshows
> > > happening
> > > > at
> > > > > > meetups etc. that we just cant do these days in most places now.
> > > > > >
> > > > > > What is your thinking on format?
> > > > > >
> > > > > > +1 in general though - that goes for anybody that wants to do
> > > something
> > > > > > like this.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Jul 28, 2020 at 12:21 PM Ekaterina Dimitrova <
> > > > e.dimitr...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > >> Hello everyone,
> > > > > >> I hope everyone is doing well in these weird pandemic times.
> > > > > >>
> > > > > >> I am super excited to see people already testing 4.0 Beta and
> > coming
> > > > back
> > > > > >> with feedback. To me the user experience is one of the most
> > > important
> > > > > >> factors for a successful release.
> > > > > >> While talking about ApacheCon™ last week, an idea was born. How
> > does
> > > > the
> > > > > >> community feel about having a workshop on Cassandra 4.0 in
> August?
> > > > > >> Why do I find this idea great?
> > > > > >> 1) Let’s keep the momentum going and try to get the attention of
> > > even
> > > > more
> > > > > >> users to start testing.
> > > > > >> 2) ApacheCon™ is only at the end of September, so we can also
> use
> > > the
> > > > > >> opp

[DISCUSS] CASSANDRA Jira modification - add Doc Impact field

[Lorina Poland]

This morning, Caleb Rackliffe mentioned to me that CASSANDRA-15907 involved
some code work that has Documentation implications, just to let me know.

I'd like to propose a change to the Cassandra Jira system, to include a
field called "Doc Impact" that a developer could check if there is
accompanying documentation that should be written. It would help with
discovery, so that a corresponding  _Documentation%Website_ Jira ticket
could be written for the work.

At DataStax, I've gone even a step further and added an automation rule
that makes a copy of the original ticket if the Doc Impact field is
checked. I would love to have that as well, but would be happy just for the
Doc Impact field. If Doc Impact was mandatory when a ticket moves from
review to merge, for instance, that would be useful, too.

Thanks,
Lorina Poland

Re: [DISCUSS] CASSANDRA Jira modification - add Doc Impact field

[Brandon Williams]

Thanks, Lorina. I'm +1 for this, but as a jira admin I briefly looked
into adding it, and I suspect we may need to involve infra, if we
decide this is something we want.

On Fri, Jul 31, 2020 at 2:28 PM Lorina Poland  wrote:
>
> This morning, Caleb Rackliffe mentioned to me that CASSANDRA-15907 involved
> some code work that has Documentation implications, just to let me know.
>
> I'd like to propose a change to the Cassandra Jira system, to include a
> field called "Doc Impact" that a developer could check if there is
> accompanying documentation that should be written. It would help with
> discovery, so that a corresponding  _Documentation%Website_ Jira ticket
> could be written for the work.
>
> At DataStax, I've gone even a step further and added an automation rule
> that makes a copy of the original ticket if the Doc Impact field is
> checked. I would love to have that as well, but would be happy just for the
> Doc Impact field. If Doc Impact was mandatory when a ticket moves from
> review to merge, for instance, that would be useful, too.
>
> Thanks,
> Lorina Poland

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] CASSANDRA Jira modification - add Doc Impact field

[Benedict Elliott Smith]

Impacts -> Docs

It's not mandatory, but we could perhaps consider making it so somewhere in the 
workflow.  Do you have a good suggestion for where?

There's also "Test and Documentation Plan" which is already mandatory.


On 31/07/2020, 20:28, "Lorina Poland"  wrote:

This morning, Caleb Rackliffe mentioned to me that CASSANDRA-15907 involved
some code work that has Documentation implications, just to let me know.

I'd like to propose a change to the Cassandra Jira system, to include a
field called "Doc Impact" that a developer could check if there is
accompanying documentation that should be written. It would help with
discovery, so that a corresponding  _Documentation%Website_ Jira ticket
could be written for the work.

At DataStax, I've gone even a step further and added an automation rule
that makes a copy of the original ticket if the Doc Impact field is
checked. I would love to have that as well, but would be happy just for the
Doc Impact field. If Doc Impact was mandatory when a ticket moves from
review to merge, for instance, that would be useful, too.

Thanks,
Lorina Poland



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] CASSANDRA Jira modification - add Doc Impact field

[Lorina Poland]

I believe that the Test and Documentation Plan field is required too early
in the progress for Documentation needs. It is mandatory to move a ticket
to "In Progress". I suspect that, while a developer may say something in
this field, they won't really be sure of the doc impact at that stage.

I would find it useful to have a mandatory Doc Impact field before a ticket
moves from "In Progress" to "Patch Available". The design and
implementation of the code work will be uppermost at that point, when the
developer has finally made the code changes.

I see tickets that have wonderful design docs early in the process. But as
the work progresses, the design changes, and those changes are not captured
in any summary manner.

For instance, I'm currently working to rewrite audit logging (
https://issues.apache.org/jira/browse/CASSANDRA-12151). Weeding through 4
years of comments and changes is challenging. If the developer had marked
Doc Impact and perhaps written some Doc Notes right before "Patch
Available", I'd feel much more confident that I understand what the
submitted change is. For some development, I can look at the code and
figure out what it does. A topic like audit logging is likely to use many
classes and touch on many items that I'm not familiar with nor be the most
readable code.

Lorina Poland




On Fri, Jul 31, 2020 at 12:35 PM Benedict Elliott Smith 
wrote:

> Impacts -> Docs
>
> It's not mandatory, but we could perhaps consider making it so somewhere
> in the workflow.  Do you have a good suggestion for where?
>
> There's also "Test and Documentation Plan" which is already mandatory.
>
>
> On 31/07/2020, 20:28, "Lorina Poland"  wrote:
>
> This morning, Caleb Rackliffe mentioned to me that CASSANDRA-15907
> involved
> some code work that has Documentation implications, just to let me
> know.
>
> I'd like to propose a change to the Cassandra Jira system, to include a
> field called "Doc Impact" that a developer could check if there is
> accompanying documentation that should be written. It would help with
> discovery, so that a corresponding  _Documentation%Website_ Jira ticket
> could be written for the work.
>
> At DataStax, I've gone even a step further and added an automation rule
> that makes a copy of the original ticket if the Doc Impact field is
> checked. I would love to have that as well, but would be happy just
> for the
> Doc Impact field. If Doc Impact was mandatory when a ticket moves from
> review to merge, for instance, that would be useful, too.
>
> Thanks,
> Lorina Poland
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] CASSANDRA Jira modification - add Doc Impact field

[Benedict Elliott Smith]

> It is mandatory to move a ticket to "In Progress"

I think you are mistaken; I have triple-checked, and it appears to be required 
on "Submit Patch" - the problem is that nobody really fills it out very well.  
Being mandatory is insufficient.

Also, to clarify my earlier email, there already exists a field called 
"Impacts" which includes "Docs" as an option to indicate there exists a 
documentation impact to consider, mostly to support search.


On 31/07/2020, 20:51, "Lorina Poland"  wrote:

I believe that the Test and Documentation Plan field is required too early
in the progress for Documentation needs. It is mandatory to move a ticket
to "In Progress". I suspect that, while a developer may say something in
this field, they won't really be sure of the doc impact at that stage.

I would find it useful to have a mandatory Doc Impact field before a ticket
moves from "In Progress" to "Patch Available". The design and
implementation of the code work will be uppermost at that point, when the
developer has finally made the code changes.

I see tickets that have wonderful design docs early in the process. But as
the work progresses, the design changes, and those changes are not captured
in any summary manner.

For instance, I'm currently working to rewrite audit logging (
https://issues.apache.org/jira/browse/CASSANDRA-12151). Weeding through 4
years of comments and changes is challenging. If the developer had marked
Doc Impact and perhaps written some Doc Notes right before "Patch
Available", I'd feel much more confident that I understand what the
submitted change is. For some development, I can look at the code and
figure out what it does. A topic like audit logging is likely to use many
classes and touch on many items that I'm not familiar with nor be the most
readable code.

Lorina Poland




On Fri, Jul 31, 2020 at 12:35 PM Benedict Elliott Smith 

wrote:

> Impacts -> Docs
>
> It's not mandatory, but we could perhaps consider making it so somewhere
> in the workflow.  Do you have a good suggestion for where?
>
> There's also "Test and Documentation Plan" which is already mandatory.
>
>
> On 31/07/2020, 20:28, "Lorina Poland"  wrote:
>
> This morning, Caleb Rackliffe mentioned to me that CASSANDRA-15907
> involved
> some code work that has Documentation implications, just to let me
> know.
>
> I'd like to propose a change to the Cassandra Jira system, to include 
a
> field called "Doc Impact" that a developer could check if there is
> accompanying documentation that should be written. It would help with
> discovery, so that a corresponding  _Documentation%Website_ Jira 
ticket
> could be written for the work.
>
> At DataStax, I've gone even a step further and added an automation 
rule
> that makes a copy of the original ticket if the Doc Impact field is
> checked. I would love to have that as well, but would be happy just
> for the
> Doc Impact field. If Doc Impact was mandatory when a ticket moves from
> review to merge, for instance, that would be useful, too.
>
> Thanks,
> Lorina Poland
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] CASSANDRA Jira modification - add Doc Impact field

[Lorina Poland]

I was just working from this doc:
https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals

Test and Documentation Plan
> A new required field containing free-form text field, required when
> transitioning to 'In Progress'.
> The intended purpose is to encourage explicit upfront consideration of the
> work needed on these areas
> either before or following commit. This may entail filing follow-up
> tickets that need to be resolved before release,
> or a brief statement on the tests that will be written, or simply 'n/a'.
> This also provides a promise to hold implementors to before release, and a
> point of discussion before a ticket lands.

Now that you pointed it out, I do see the "Impacts" field. A search of:

*Impacts in (Docs) and project in (Cassandra) and fixVersion in (4.0)*

does turn up what I'm looking for in terms of knowing about tickets that
require docs.

The automation rule would still be nice, and could be triggered when
Impacts = Docs.

Thanks for the info, Benedict!

Lorina Poland




On Fri, Jul 31, 2020 at 1:10 PM Benedict Elliott Smith 
wrote:

> > It is mandatory to move a ticket to "In Progress"
>
> I think you are mistaken; I have triple-checked, and it appears to be
> required on "Submit Patch" - the problem is that nobody really fills it out
> very well.  Being mandatory is insufficient.
>
> Also, to clarify my earlier email, there already exists a field called
> "Impacts" which includes "Docs" as an option to indicate there exists a
> documentation impact to consider, mostly to support search.
>
>
> On 31/07/2020, 20:51, "Lorina Poland"  wrote:
>
> I believe that the Test and Documentation Plan field is required too
> early
> in the progress for Documentation needs. It is mandatory to move a
> ticket
> to "In Progress". I suspect that, while a developer may say something
> in
> this field, they won't really be sure of the doc impact at that stage.
>
> I would find it useful to have a mandatory Doc Impact field before a
> ticket
> moves from "In Progress" to "Patch Available". The design and
> implementation of the code work will be uppermost at that point, when
> the
> developer has finally made the code changes.
>
> I see tickets that have wonderful design docs early in the process.
> But as
> the work progresses, the design changes, and those changes are not
> captured
> in any summary manner.
>
> For instance, I'm currently working to rewrite audit logging (
> https://issues.apache.org/jira/browse/CASSANDRA-12151). Weeding
> through 4
> years of comments and changes is challenging. If the developer had
> marked
> Doc Impact and perhaps written some Doc Notes right before "Patch
> Available", I'd feel much more confident that I understand what the
> submitted change is. For some development, I can look at the code and
> figure out what it does. A topic like audit logging is likely to use
> many
> classes and touch on many items that I'm not familiar with nor be the
> most
> readable code.
>
> Lorina Poland
>
>
>
>
> On Fri, Jul 31, 2020 at 12:35 PM Benedict Elliott Smith <
> bened...@apache.org>
> wrote:
>
> > Impacts -> Docs
> >
> > It's not mandatory, but we could perhaps consider making it so
> somewhere
> > in the workflow.  Do you have a good suggestion for where?
> >
> > There's also "Test and Documentation Plan" which is already
> mandatory.
> >
> >
> > On 31/07/2020, 20:28, "Lorina Poland"  wrote:
> >
> > This morning, Caleb Rackliffe mentioned to me that
> CASSANDRA-15907
> > involved
> > some code work that has Documentation implications, just to let
> me
> > know.
> >
> > I'd like to propose a change to the Cassandra Jira system, to
> include a
> > field called "Doc Impact" that a developer could check if there
> is
> > accompanying documentation that should be written. It would help
> with
> > discovery, so that a corresponding  _Documentation%Website_ Jira
> ticket
> > could be written for the work.
> >
> > At DataStax, I've gone even a step further and added an
> automation rule
> > that makes a copy of the original ticket if the Doc Impact field
> is
> > checked. I would love to have that as well, but would be happy
> just
> > for the
> > Doc Impact field. If Doc Impact was mandatory when a ticket
> moves from
> > review to merge, for instance, that would be useful, too.
> >
> > Thanks,
> > Lorina Poland
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ca

Re: [DISCUSS] CASSANDRA Jira modification - add Doc Impact field

[Benedict Elliott Smith]

Ironically, those docs are inaccurate! 


On 31/07/2020, 21:25, "Lorina Poland"  wrote:

I was just working from this doc:

https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals

Test and Documentation Plan
> A new required field containing free-form text field, required when
> transitioning to 'In Progress'.
> The intended purpose is to encourage explicit upfront consideration of the
> work needed on these areas
> either before or following commit. This may entail filing follow-up
> tickets that need to be resolved before release,
> or a brief statement on the tests that will be written, or simply 'n/a'.
> This also provides a promise to hold implementors to before release, and a
> point of discussion before a ticket lands.

Now that you pointed it out, I do see the "Impacts" field. A search of:

*Impacts in (Docs) and project in (Cassandra) and fixVersion in (4.0)*

does turn up what I'm looking for in terms of knowing about tickets that
require docs.

The automation rule would still be nice, and could be triggered when
Impacts = Docs.

Thanks for the info, Benedict!

Lorina Poland




On Fri, Jul 31, 2020 at 1:10 PM Benedict Elliott Smith 
wrote:

> > It is mandatory to move a ticket to "In Progress"
>
> I think you are mistaken; I have triple-checked, and it appears to be
> required on "Submit Patch" - the problem is that nobody really fills it 
out
> very well.  Being mandatory is insufficient.
>
> Also, to clarify my earlier email, there already exists a field called
> "Impacts" which includes "Docs" as an option to indicate there exists a
> documentation impact to consider, mostly to support search.
>
>
> On 31/07/2020, 20:51, "Lorina Poland"  wrote:
>
> I believe that the Test and Documentation Plan field is required too
> early
> in the progress for Documentation needs. It is mandatory to move a
> ticket
> to "In Progress". I suspect that, while a developer may say something
> in
> this field, they won't really be sure of the doc impact at that stage.
>
> I would find it useful to have a mandatory Doc Impact field before a
> ticket
> moves from "In Progress" to "Patch Available". The design and
> implementation of the code work will be uppermost at that point, when
> the
> developer has finally made the code changes.
>
> I see tickets that have wonderful design docs early in the process.
> But as
> the work progresses, the design changes, and those changes are not
> captured
> in any summary manner.
>
> For instance, I'm currently working to rewrite audit logging (
> https://issues.apache.org/jira/browse/CASSANDRA-12151). Weeding
> through 4
> years of comments and changes is challenging. If the developer had
> marked
> Doc Impact and perhaps written some Doc Notes right before "Patch
> Available", I'd feel much more confident that I understand what the
> submitted change is. For some development, I can look at the code and
> figure out what it does. A topic like audit logging is likely to use
> many
> classes and touch on many items that I'm not familiar with nor be the
> most
> readable code.
>
> Lorina Poland
>
>
>
>
> On Fri, Jul 31, 2020 at 12:35 PM Benedict Elliott Smith <
> bened...@apache.org>
> wrote:
>
> > Impacts -> Docs
> >
> > It's not mandatory, but we could perhaps consider making it so
> somewhere
> > in the workflow.  Do you have a good suggestion for where?
> >
> > There's also "Test and Documentation Plan" which is already
> mandatory.
> >
> >
> > On 31/07/2020, 20:28, "Lorina Poland"  wrote:
> >
> > This morning, Caleb Rackliffe mentioned to me that
> CASSANDRA-15907
> > involved
> > some code work that has Documentation implications, just to let
> me
> > know.
> >
> > I'd like to propose a change to the Cassandra Jira system, to
> include a
> > field called "Doc Impact" that a developer could check if there
> is
> > accompanying documentation that should be written. It would help
> with
> > discovery, so that a corresponding  _Documentation%Website_ Jira
> ticket
> > could be written for the work.
> >
> > At DataStax, I've gone even a step further and added an
> automation rule
> > that makes a copy of the original ticket if the Doc Impact field
> is
> > checked. I would love to have that as well, but would be happy
> just
> > for the
> > Doc Impact field. If 

Re: [DISCUSS] CASSANDRA Jira modification - add Doc Impact field

[Erick Ramirez]

>
>  and it appears to be required on "Submit Patch" - the problem is that
> nobody really fills it out very well.  Being mandatory is insufficient.
>

+1 I agree. Wherever this ends up in the workflow, I'd like to suggest that
a reviewer verify that doc updates are *not* required as part of the "exit"
criteria. Thoughts?

Re: [DISCUSS] CASSANDRA Jira modification - add Doc Impact field

[Ekaterina Dimitrova]

+1, both author and reviewer have to ensure that documentation is not
missed, not less important than any code. Bad documentation can make a
great feature looking really bad. I know “test and documentation” is
already mandatory so the only thing that appears now on my mind is to
remind everyone not to forget it and to keep on reminding each other, I
guess.
Or maybe to add some template with a couple of specific questions that need
to be answered?
Example: “Does this patch require a new documentation page?
Does this patch require documentation update?
Please verify any related documentation is clear enough for the users”

Maybe it will be a bit too much but if the required field is not enough and
if we think something more needs to be done...

Best regards,
Ekaterina

On Fri, 31 Jul 2020 at 19:56, Erick Ramirez 
wrote:

> >
> >  and it appears to be required on "Submit Patch" - the problem is that
> > nobody really fills it out very well.  Being mandatory is insufficient.
> >
>
> +1 I agree. Wherever this ends up in the workflow, I'd like to suggest that
> a reviewer verify that doc updates are *not* required as part of the "exit"
> criteria. Thoughts?
>