Re: [petsc-dev] Prediscusion of appropriate communication tool for discussion of PETSc 4 aka the Grand Refactorization

[Hapla Vaclav]

These issues could also have a special milestone like "future". The issue list 
allows filtering per milestone (= or !=).

Vaclav

On 20 Jun 2020, at 19:09, Barry Smith 
mailto:bsm...@petsc.dev>> wrote:


   I'm leaning to Vaclav's proposal, but with multiple issues, running in the 
PETSc repository as Jed suggested. My concern about the clutter of issues is 
outweighed by Jed's statement of having the history in one place (current PETSc 
repository) and Jacob's observation we can cleanly do links to MR, other 
issues, etc For example, someone does a prototype it can be right there and 
trivially accessible.

   The drawback to the mailing list is if we have just one then people have to 
very carefully label the topic of each one and if we have 10 then people have 
to set up ten mail boxes for them or have them all cluttered together and a 
pain to read.

   Unless I hear some other great ideas I will start setting up my issues with 
some notational consistency and we can start communicating and people can add 
their own issues as needed.

   Barry


On Jun 20, 2020, at 12:42 AM, Fande Kong 
mailto:fdkong...@gmail.com>> wrote:

The mailing list sounds a perfect option.

Thanks,

Fande,



On Thu, Jun 18, 2020 at 10:49 PM Jed Brown 
mailto:j...@jedbrown.org>> wrote:
I would prefer this mailing list or GitLab issues because they are

1. genuinely open to external participants,
2. more async-friendly for those in different timezones and folks with young 
kids, and
3. searchable and externally linkable (e.g., from merge requests and issues)

If we need synchronous breakouts, we could do so, but there should be a summary 
back for those who couldn't participate synchronously.

Barry Smith mailto:bsm...@petsc.dev>> writes:

>I'd like to start a discussion of PETSc 4.0 aka the Grand Refactorization 
> but to have that discussion we need to discuss what tool to use for that 
> discussion.
>
>So this discussion is not about PETSc 4.0, please don't discuss it here.
>
>What do people recommend to use for the discussion
>
>   * dedicated mailing list
>   * slack channel(s)
>   * zulip channel(s)
>   * something else?
>
>   I'd like a single tool that anyone can join at any time, see the full 
> history, can attach files, search, not cost more money the we are already 
> paying, etc.
>
>   I expect this discussion to take maybe a week and then the actual 
> discussion to take on the order of two months.
>
>Thanks
>
>  Barry
>
>

Re: [petsc-dev] Prediscusion of appropriate communication tool for discussion of PETSc 4 aka the Grand Refactorization

[Barry Smith]

   I'm leaning to Vaclav's proposal, but with multiple issues, running in the 
PETSc repository as Jed suggested. My concern about the clutter of issues is 
outweighed by Jed's statement of having the history in one place (current PETSc 
repository) and Jacob's observation we can cleanly do links to MR, other 
issues, etc For example, someone does a prototype it can be right there and 
trivially accessible.

   The drawback to the mailing list is if we have just one then people have to 
very carefully label the topic of each one and if we have 10 then people have 
to set up ten mail boxes for them or have them all cluttered together and a 
pain to read. 

   Unless I hear some other great ideas I will start setting up my issues with 
some notational consistency and we can start communicating and people can add 
their own issues as needed.

   Barry


> On Jun 20, 2020, at 12:42 AM, Fande Kong  wrote:
> 
> The mailing list sounds a perfect option. 
> 
> Thanks,
> 
> Fande,
> 
> 
> 
> On Thu, Jun 18, 2020 at 10:49 PM Jed Brown  > wrote:
> I would prefer this mailing list or GitLab issues because they are
> 
> 1. genuinely open to external participants,
> 2. more async-friendly for those in different timezones and folks with young 
> kids, and
> 3. searchable and externally linkable (e.g., from merge requests and issues)
> 
> If we need synchronous breakouts, we could do so, but there should be a 
> summary back for those who couldn't participate synchronously.
> 
> Barry Smith mailto:bsm...@petsc.dev>> writes:
> 
> >I'd like to start a discussion of PETSc 4.0 aka the Grand 
> > Refactorization but to have that discussion we need to discuss what tool to 
> > use for that discussion. 
> >
> >So this discussion is not about PETSc 4.0, please don't discuss it here.
> >
> >What do people recommend to use for the discussion
> >
> >   * dedicated mailing list
> >   * slack channel(s)
> >   * zulip channel(s)
> >   * something else?
> >
> >   I'd like a single tool that anyone can join at any time, see the full 
> > history, can attach files, search, not cost more money the we are already 
> > paying, etc.
> >
> >   I expect this discussion to take maybe a week and then the actual 
> > discussion to take on the order of two months.
> >
> >Thanks
> >
> >  Barry
> >
> >   

Re: [petsc-dev] Prediscusion of appropriate communication tool for discussion of PETSc 4 aka the Grand Refactorization

[Fande Kong]

The mailing list sounds a perfect option.

Thanks,

Fande,



On Thu, Jun 18, 2020 at 10:49 PM Jed Brown  wrote:

> I would prefer this mailing list or GitLab issues because they are
>
> 1. genuinely open to external participants,
> 2. more async-friendly for those in different timezones and folks with
> young kids, and
> 3. searchable and externally linkable (e.g., from merge requests and
> issues)
>
> If we need synchronous breakouts, we could do so, but there should be a
> summary back for those who couldn't participate synchronously.
>
> Barry Smith  writes:
>
> >I'd like to start a discussion of PETSc 4.0 aka the Grand
> Refactorization but to have that discussion we need to discuss what tool to
> use for that discussion.
> >
> >So this discussion is not about PETSc 4.0, please don't discuss it
> here.
> >
> >What do people recommend to use for the discussion
> >
> >   * dedicated mailing list
> >   * slack channel(s)
> >   * zulip channel(s)
> >   * something else?
> >
> >   I'd like a single tool that anyone can join at any time, see the full
> history, can attach files, search, not cost more money the we are already
> paying, etc.
> >
> >   I expect this discussion to take maybe a week and then the actual
> discussion to take on the order of two months.
> >
> >Thanks
> >
> >  Barry
> >
> >
>

Re: [petsc-dev] Prediscusion of appropriate communication tool for discussion of PETSc 4 aka the Grand Refactorization

[Jed Brown]

"Hapla  Vaclav"  writes:

> OK, but you just enabled it, didn't you? When I look at whatever issue, it is 
> disabled and still I get all notifications.

I didn't change it; I'm usually subscribed due to being an integrator.  Perhaps 
your "watch" setting overrides the notifications toggle (report it as a bug if 
so).

Re: [petsc-dev] Prediscusion of appropriate communication tool for discussion of PETSc 4 aka the Grand Refactorization

[Barry Smith]

  If we go with the multiple issues (in the same or a different repository) I 
would create an email filter that directed all the email notifications about 
those issues into their own mail box.

  I currently have petsc-users, petsc-pipeline, petsc-gitlab, petsc-maint, and 
petsc-dev mailboxes so would just add something like petsc-future


> On Jun 19, 2020, at 3:18 PM, Hapla Vaclav  wrote:
> 
>> 
>> On 19 Jun 2020, at 20:39, j...@jedbrown.org  wrote:
>> 
>> I'd expect we'd have a handful of issues with a common label. Easy to 
>> customize notifications.
> 
> Notification scope is either global, group or project. 
> 
>  So you can't e.g. mute a single issue and keep others fully notifying, 
> right? But not a big deal probably - I guess those who listen to all the 
> current issue traffic will be interested anyway.
> 
>> I don't see the point of a special repository except that it becomes less 
>> discoverable.
>> 
>> On Jun 19, 2020 12:25, Hapla Vaclav > > wrote:
>> Why not have a separate project within the same group 
>> https://gitlab.com/petsc?  That would allow 
>> separate notification settings, for instance. Or the GitLab's Snippets 
>> feature mentioned by Jacob - I can imagine they might be confusing within 
>> the current repo if they would refer to a future API.
>> 
>> That new repo can be kept forever for reference, if preferred. I don't see 
>> why it couldn't be referred to later.
>> 
>> Anyway, Epics would be cool even for the current development.
>> 
>> Vaclav
>> 
>> On 19 Jun 2020, at 20:14, j...@jedbrown.org  wrote:
>> 
>> GitLab has Epics for managing related issues (we'd have to request community 
>> project status to activate it). I don't know if that feature helps 
>> facilitate what you envision. If using present features, I would have one 
>> outline issue and an issue for each major component. I'd rather not create a 
>> new repository. The institutional knowledge in the discussion can be useful 
>> to refer to later.
>> 
>> On Jun 19, 2020 12:03, Barry Smith > > wrote:
>> 
>>   We could create a new empty repository just to use the issue tracker, then 
>> we could have the discussion in multiple issues. (having links to PETSc code 
>> etc would then require full paths).
>> 
>>   Each design topic, of which there will be dozens, would get its own issue 
>> and new topics are trivial added. People can watch the topics they care 
>> about. Plus an issue for general discussion.
>> 
>>   Barry
>> 
>> 
>> On Jun 19, 2020, at 12:57 PM, Jacob Faibussowitsch > > wrote:
>> 
>> I think a special GitLab issue (something akin #360 CI Tracker) would do the 
>> job quite nicely.
>> I agree more with this. This also allows you to immediately see the list of 
>> linked MR’s and issues right in the conversation, as well as being able to 
>> link code snippets. One gripe however is that the issue becomes monolithic 
>> with multiple conversation threads (as you can see the CI error issue is a 
>> totally unstructured Smörgåsbord). To keep a more structured overview we 
>> should have multiple issues that are linked together. 
>> 
>> Best regards,
>> 
>> Jacob Faibussowitsch
>> (Jacob Fai - booss - oh - vitch)
>> Cell: (312) 694-3391
>> 
>> On Jun 19, 2020, at 12:34 PM, Hapla Vaclav > > wrote:
>> 
>> I like Slack but it does NOT have the full history in the free plan - it's 
>> limited to 10k messages.
>> 
>> I think a special GitLab issue (something akin #360 CI Tracker) would do the 
>> job quite nicely.
>> 
>> Vaclav
>> 
>> On 19 Jun 2020, at 06:48, Jed Brown > > wrote:
>> 
>> I would prefer this mailing list or GitLab issues because they are
>> 
>> 1. genuinely open to external participants,
>> 2. more async-friendly for those in different timezones and folks with young 
>> kids, and
>> 3. searchable and externally linkable (e.g., from merge requests and issues)
>> 
>> If we need synchronous breakouts, we could do so, but there should be a 
>> summary back for those who couldn't participate synchronously.
>> 
>> Barry Smith mailto:bsm...@petsc.dev>> writes:
>> 
>>  I'd like to start a discussion of PETSc 4.0 aka the Grand Refactorization 
>> but to have that discussion we need to discuss what tool to use for that 
>> discussion. 
>> 
>>  So this discussion is not about PETSc 4.0, please don't discuss it here.
>> 
>>  What do people recommend to use for the discussion
>> 
>> * dedicated mailing list
>> * slack channel(s)
>> * zulip channel(s)
>> * something else?
>> 
>> I'd like a single tool that anyone can join at any time, see the full 
>> history, can attach files, search, not cost more money the we are already 
>> paying, etc.
>> 
>> I expect this discussion to take maybe 

Re: [petsc-dev] Prediscusion of appropriate communication tool for discussion of PETSc 4 aka the Grand Refactorization

[Hapla Vaclav]

On 19 Jun 2020, at 20:39, j...@jedbrown.org wrote:

I'd expect we'd have a handful of issues with a common label. Easy to customize 
notifications.

Notification scope is either global, group or 
project.
 So you can't e.g. mute a single issue and keep others fully notifying, right? 
But not a big deal probably - I guess those who listen to all the current issue 
traffic will be interested anyway.

I don't see the point of a special repository except that it becomes less 
discoverable.

On Jun 19, 2020 12:25, Hapla Vaclav 
mailto:vaclav.ha...@erdw.ethz.ch>> wrote:
Why not have a separate project within the same group https://gitlab.com/petsc? 
That would allow separate notification settings, for instance. Or the GitLab's 
Snippets feature mentioned by Jacob - I can imagine they might be confusing 
within the current repo if they would refer to a future API.

That new repo can be kept forever for reference, if preferred. I don't see why 
it couldn't be referred to later.

Anyway, Epics would be cool even for the current development.

Vaclav

On 19 Jun 2020, at 20:14, j...@jedbrown.org wrote:

GitLab has Epics for managing related issues (we'd have to request community 
project status to activate it). I don't know if that feature helps facilitate 
what you envision. If using present features, I would have one outline issue 
and an issue for each major component. I'd rather not create a new repository. 
The institutional knowledge in the discussion can be useful to refer to later.

On Jun 19, 2020 12:03, Barry Smith mailto:bsm...@petsc.dev>> 
wrote:

  We could create a new empty repository just to use the issue tracker, then we 
could have the discussion in multiple issues. (having links to PETSc code etc 
would then require full paths).

  Each design topic, of which there will be dozens, would get its own issue and 
new topics are trivial added. People can watch the topics they care about. Plus 
an issue for general discussion.

  Barry


On Jun 19, 2020, at 12:57 PM, Jacob Faibussowitsch 
mailto:jacob@gmail.com>> wrote:

I think a special GitLab issue (something akin #360 CI Tracker) would do the 
job quite nicely.
I agree more with this. This also allows you to immediately see the list of 
linked MR’s and issues right in the conversation, as well as being able to link 
code snippets. One gripe however is that the issue becomes monolithic with 
multiple conversation threads (as you can see the CI error issue is a totally 
unstructured Smörgåsbord). To keep a more structured overview we should have 
multiple issues that are linked together.

Best regards,

Jacob Faibussowitsch
(Jacob Fai - booss - oh - vitch)
Cell: (312) 694-3391

On Jun 19, 2020, at 12:34 PM, Hapla Vaclav 
mailto:vaclav.ha...@erdw.ethz.ch>> wrote:

I like Slack but it does NOT have the full history in the free plan - it's 
limited to 10k messages.

I think a special GitLab issue (something akin #360 CI Tracker) would do the 
job quite nicely.

Vaclav

On 19 Jun 2020, at 06:48, Jed Brown 
mailto:j...@jedbrown.org>> wrote:

I would prefer this mailing list or GitLab issues because they are

1. genuinely open to external participants,
2. more async-friendly for those in different timezones and folks with young 
kids, and
3. searchable and externally linkable (e.g., from merge requests and issues)

If we need synchronous breakouts, we could do so, but there should be a summary 
back for those who couldn't participate synchronously.

Barry Smith mailto:bsm...@petsc.dev>> writes:

 I'd like to start a discussion of PETSc 4.0 aka the Grand Refactorization but 
to have that discussion we need to discuss what tool to use for that discussion.

 So this discussion is not about PETSc 4.0, please don't discuss it here.

 What do people recommend to use for the discussion

* dedicated mailing list
* slack channel(s)
* zulip channel(s)
* something else?

I'd like a single tool that anyone can join at any time, see the full history, 
can attach files, search, not cost more money the we are already paying, etc.

I expect this discussion to take maybe a week and then the actual discussion to 
take on the order of two months.

 Thanks

   Barry

Re: [petsc-dev] Prediscusion of appropriate communication tool for discussion of PETSc 4 aka the Grand Refactorization

[Patrick Sanan]

The Gitlab wiki (on whichever repo) might also be a good complement to
whichever thread-based option is used.

 schrieb am Fr. 19. Juni 2020 um 20:39:

> I'd expect we'd have a handful of issues with a common label. Easy to
> customize notifications. I don't see the point of a special repository
> except that it becomes less discoverable.
>
> On Jun 19, 2020 12:25, Hapla Vaclav  wrote:
>
> Why not have a separate project within the same group
> https://gitlab.com/petsc? That would allow separate notification
> settings, for instance. Or the GitLab's Snippets feature mentioned by Jacob
> - I can imagine they might be confusing within the current repo if they
> would refer to a future API.
>
> That new repo can be kept forever for reference, if preferred. I don't see
> why it couldn't be referred to later.
>
> Anyway, Epics would be cool even for the current development.
>
> Vaclav
>
> On 19 Jun 2020, at 20:14, j...@jedbrown.org wrote:
>
> GitLab has Epics for managing related issues (we'd have to request
> community project status to activate it). I don't know if that feature
> helps facilitate what you envision. If using present features, I would have
> one outline issue and an issue for each major component. I'd rather not
> create a new repository. The institutional knowledge in the discussion can
> be useful to refer to later.
>
> On Jun 19, 2020 12:03, Barry Smith  wrote:
>
>
>   We could create a new empty repository just to use the issue tracker,
> then we could have the discussion in multiple issues. (having links to
> PETSc code etc would then require full paths).
>
>   Each design topic, of which there will be dozens, would get its own
> issue and new topics are trivial added. People can watch the topics they
> care about. Plus an issue for general discussion.
>
>   Barry
>
>
> On Jun 19, 2020, at 12:57 PM, Jacob Faibussowitsch 
> wrote:
>
> I think a special GitLab issue (something akin #360 CI Tracker) would do
> the job quite nicely.
>
> I agree more with this. This also allows you to immediately see the list
> of linked MR’s and issues right in the conversation, as well as being able
> to link code snippets. One gripe however is that the issue becomes
> monolithic with multiple conversation threads (as you can see the CI error
> issue is a totally unstructured Smörgåsbord). To keep a more structured
> overview we should have multiple issues that are linked together.
>
> Best regards,
>
> Jacob Faibussowitsch
> (Jacob Fai - booss - oh - vitch)
> Cell: (312) 694-3391
>
> On Jun 19, 2020, at 12:34 PM, Hapla Vaclav 
> wrote:
>
> I like Slack but it does NOT have the full history in the free plan - it's
> limited to 10k messages.
>
> I think a special GitLab issue (something akin #360 CI Tracker) would do
> the job quite nicely.
>
> Vaclav
>
> On 19 Jun 2020, at 06:48, Jed Brown  wrote:
>
> I would prefer this mailing list or GitLab issues because they are
>
> 1. genuinely open to external participants,
> 2. more async-friendly for those in different timezones and folks with
> young kids, and
> 3. searchable and externally linkable (e.g., from merge requests and
> issues)
>
> If we need synchronous breakouts, we could do so, but there should be a
> summary back for those who couldn't participate synchronously.
>
> Barry Smith  writes:
>
>  I'd like to start a discussion of PETSc 4.0 aka the Grand Refactorization
> but to have that discussion we need to discuss what tool to use for that
> discussion.
>
>  So this discussion is not about PETSc 4.0, please don't discuss it here.
>
>  What do people recommend to use for the discussion
>
> * dedicated mailing list
> * slack channel(s)
> * zulip channel(s)
> * something else?
>
> I'd like a single tool that anyone can join at any time, see the full
> history, can attach files, search, not cost more money the we are already
> paying, etc.
>
> I expect this discussion to take maybe a week and then the actual
> discussion to take on the order of two months.
>
>  Thanks
>
>Barry
>
>
>
>
>
>
>
>
>

Re: [petsc-dev] Prediscusion of appropriate communication tool for discussion of PETSc 4 aka the Grand Refactorization

[jed]

I'd expect we'd have a handful of issues with a common label. Easy to customize notifications. I don't see the point of a special repository except that it becomes less discoverable.On Jun 19, 2020 12:25, Hapla  Vaclav  wrote:
Why not have a separate project within the same group https://gitlab.com/petsc? That would allow separate notification settings, for instance. Or the GitLab's Snippets feature mentioned by Jacob - I can imagine
 they might be confusing within the current repo if they would refer to a future API.


That new repo can be kept forever for reference, if preferred. I don't see why it couldn't be referred to later.


Anyway, Epics would be cool even for the current development.


Vaclav




On 19 Jun 2020, at 20:14, 
jed@jedbrown.org wrote:


GitLab has Epics for managing related issues (we'd have to request community project status to activate it). I don't know if that feature helps facilitate what you envision. If using present features, I would have one outline issue
 and an issue for each major component. I'd rather not create a new repository. The institutional knowledge in the discussion can be useful to refer to later.

On Jun 19, 2020 12:03, Barry Smith  wrote:




  We could create a new empty repository just to use the issue tracker, then we could have the discussion in multiple issues. (having links to PETSc code etc would then require full paths).


  Each design topic, of which there will be dozens, would get its own issue and new topics are trivial added. People can watch the topics they care about. Plus an issue for general discussion.


  Barry



On Jun 19, 2020, at 12:57 PM, Jacob Faibussowitsch  wrote:



I think a special GitLab issue (something akin #360 CI Tracker) would do the job quite nicely.
I agree more with this. This also allows you to immediately see the list of linked MR’s and issues right in the conversation, as well as being able to link code snippets. One gripe however is that the issue becomes monolithic with multiple conversation threads
 (as you can see the CI error issue is a totally unstructured Smörgåsbord). To keep a more structured overview we should have multiple issues that are linked together. 



Best regards,

Jacob Faibussowitsch
(Jacob Fai - booss - oh - vitch)
Cell: (312) 694-3391




On Jun 19, 2020, at 12:34 PM, Hapla Vaclav  wrote:


I like Slack but it does NOT have the full history in the free plan - it's limited to 10k messages.

I think a special GitLab issue (something akin #360 CI Tracker) would do the job quite nicely.

Vaclav

On 19 Jun 2020, at 06:48, Jed Brown  wrote:

I would prefer this mailing list or GitLab issues because they are

1. genuinely open to external participants,
2. more async-friendly for those in different timezones and folks with young kids, and
3. searchable and externally linkable (e.g., from merge requests and issues)

If we need synchronous breakouts, we could do so, but there should be a summary back for those who couldn't participate synchronously.

Barry Smith  writes:

 I'd like to start a discussion of PETSc 4.0 aka the Grand Refactorization but to have that discussion we need to discuss what tool to use for that discussion.


 So this discussion is not about PETSc 4.0, please don't discuss it here.

 What do people recommend to use for the discussion

* dedicated mailing list
* slack channel(s)
* zulip channel(s)
* something else?

I'd like a single tool that anyone can join at any time, see the full history, can attach files, search, not cost more money the we are already paying, etc.

I expect this discussion to take maybe a week and then the actual discussion to take on the order of two months.

 Thanks

   Barry

Re: [petsc-dev] Prediscusion of appropriate communication tool for discussion of PETSc 4 aka the Grand Refactorization

[Hapla Vaclav]

Why not have a separate project within the same group https://gitlab.com/petsc? 
That would allow separate notification settings, for instance. Or the GitLab's 
Snippets feature mentioned by Jacob - I can imagine they might be confusing 
within the current repo if they would refer to a future API.

That new repo can be kept forever for reference, if preferred. I don't see why 
it couldn't be referred to later.

Anyway, Epics would be cool even for the current development.

Vaclav

On 19 Jun 2020, at 20:14, j...@jedbrown.org wrote:

GitLab has Epics for managing related issues (we'd have to request community 
project status to activate it). I don't know if that feature helps facilitate 
what you envision. If using present features, I would have one outline issue 
and an issue for each major component. I'd rather not create a new repository. 
The institutional knowledge in the discussion can be useful to refer to later.

On Jun 19, 2020 12:03, Barry Smith mailto:bsm...@petsc.dev>> 
wrote:

  We could create a new empty repository just to use the issue tracker, then we 
could have the discussion in multiple issues. (having links to PETSc code etc 
would then require full paths).

  Each design topic, of which there will be dozens, would get its own issue and 
new topics are trivial added. People can watch the topics they care about. Plus 
an issue for general discussion.

  Barry


On Jun 19, 2020, at 12:57 PM, Jacob Faibussowitsch 
mailto:jacob@gmail.com>> wrote:

I think a special GitLab issue (something akin #360 CI Tracker) would do the 
job quite nicely.
I agree more with this. This also allows you to immediately see the list of 
linked MR’s and issues right in the conversation, as well as being able to link 
code snippets. One gripe however is that the issue becomes monolithic with 
multiple conversation threads (as you can see the CI error issue is a totally 
unstructured Smörgåsbord). To keep a more structured overview we should have 
multiple issues that are linked together.

Best regards,

Jacob Faibussowitsch
(Jacob Fai - booss - oh - vitch)
Cell: (312) 694-3391

On Jun 19, 2020, at 12:34 PM, Hapla Vaclav 
mailto:vaclav.ha...@erdw.ethz.ch>> wrote:

I like Slack but it does NOT have the full history in the free plan - it's 
limited to 10k messages.

I think a special GitLab issue (something akin #360 CI Tracker) would do the 
job quite nicely.

Vaclav

On 19 Jun 2020, at 06:48, Jed Brown 
mailto:j...@jedbrown.org>> wrote:

I would prefer this mailing list or GitLab issues because they are

1. genuinely open to external participants,
2. more async-friendly for those in different timezones and folks with young 
kids, and
3. searchable and externally linkable (e.g., from merge requests and issues)

If we need synchronous breakouts, we could do so, but there should be a summary 
back for those who couldn't participate synchronously.

Barry Smith mailto:bsm...@petsc.dev>> writes:

 I'd like to start a discussion of PETSc 4.0 aka the Grand Refactorization but 
to have that discussion we need to discuss what tool to use for that discussion.

 So this discussion is not about PETSc 4.0, please don't discuss it here.

 What do people recommend to use for the discussion

* dedicated mailing list
* slack channel(s)
* zulip channel(s)
* something else?

I'd like a single tool that anyone can join at any time, see the full history, 
can attach files, search, not cost more money the we are already paying, etc.

I expect this discussion to take maybe a week and then the actual discussion to 
take on the order of two months.

 Thanks

   Barry

Re: [petsc-dev] Prediscusion of appropriate communication tool for discussion of PETSc 4 aka the Grand Refactorization

[jed]

GitLab has Epics for managing related issues (we'd have to request community project status to activate it). I don't know if that feature helps facilitate what you envision. If using present features, I would have one outline issue and an issue for each major component. I'd rather not create a new repository. The institutional knowledge in the discussion can be useful to refer to later.On Jun 19, 2020 12:03, Barry Smith  wrote:  We could create a new empty repository just to use the issue tracker, then we could have the discussion in multiple issues. (having links to PETSc code etc would then require full paths).  Each design topic, of which there will be dozens, would get its own issue and new topics are trivial added. People can watch the topics they care about. Plus an issue for general discussion.  BarryOn Jun 19, 2020, at 12:57 PM, Jacob Faibussowitsch  wrote:I think a special GitLab issue (something akin #360 CI Tracker) would do the job quite nicely.I agree more with this. This also allows you to immediately see the list of linked MR’s and issues right in the conversation, as well as being able to link code snippets. One gripe however is that the issue becomes monolithic with multiple conversation threads (as you can see the CI error issue is a totally unstructured Smörgåsbord). To keep a more structured overview we should have multiple issues that are linked together. 
Best regards,Jacob Faibussowitsch(Jacob Fai - booss - oh - vitch)Cell: (312) 694-3391


On Jun 19, 2020, at 12:34 PM, Hapla Vaclav  wrote:I like Slack but it does NOT have the full history in the free plan - it's limited to 10k messages.I think a special GitLab issue (something akin #360 CI Tracker) would do the job quite nicely.VaclavOn 19 Jun 2020, at 06:48, Jed Brown  wrote:I would prefer this mailing list or GitLab issues because they are1. genuinely open to external participants,2. more async-friendly for those in different timezones and folks with young kids, and3. searchable and externally linkable (e.g., from merge requests and issues)If we need synchronous breakouts, we could do so, but there should be a summary back for those who couldn't participate synchronously.Barry Smith  writes:  I'd like to start a discussion of PETSc 4.0 aka the Grand Refactorization but to have that discussion we need to discuss what tool to use for that discussion.   So this discussion is not about PETSc 4.0, please don't discuss it here.  What do people recommend to use for the discussion * dedicated mailing list * slack channel(s) * zulip channel(s) * something else? I'd like a single tool that anyone can join at any time, see the full history, can attach files, search, not cost more money the we are already paying, etc. I expect this discussion to take maybe a week and then the actual discussion to take on the order of two months.  Thanks    Barry

Re: [petsc-dev] Prediscusion of appropriate communication tool for discussion of PETSc 4 aka the Grand Refactorization

[Barry Smith]

  We could create a new empty repository just to use the issue tracker, then we 
could have the discussion in multiple issues. (having links to PETSc code etc 
would then require full paths).

  Each design topic, of which there will be dozens, would get its own issue and 
new topics are trivial added. People can watch the topics they care about. Plus 
an issue for general discussion.

  Barry


> On Jun 19, 2020, at 12:57 PM, Jacob Faibussowitsch  
> wrote:
> 
>> I think a special GitLab issue (something akin #360 CI Tracker) would do the 
>> job quite nicely.
> I agree more with this. This also allows you to immediately see the list of 
> linked MR’s and issues right in the conversation, as well as being able to 
> link code snippets. One gripe however is that the issue becomes monolithic 
> with multiple conversation threads (as you can see the CI error issue is a 
> totally unstructured Smörgåsbord). To keep a more structured overview we 
> should have multiple issues that are linked together. 
> 
> Best regards,
> 
> Jacob Faibussowitsch
> (Jacob Fai - booss - oh - vitch)
> Cell: (312) 694-3391
> 
>> On Jun 19, 2020, at 12:34 PM, Hapla Vaclav > > wrote:
>> 
>> I like Slack but it does NOT have the full history in the free plan - it's 
>> limited to 10k messages.
>> 
>> I think a special GitLab issue (something akin #360 CI Tracker) would do the 
>> job quite nicely.
>> 
>> Vaclav
>> 
>>> On 19 Jun 2020, at 06:48, Jed Brown >> > wrote:
>>> 
>>> I would prefer this mailing list or GitLab issues because they are
>>> 
>>> 1. genuinely open to external participants,
>>> 2. more async-friendly for those in different timezones and folks with 
>>> young kids, and
>>> 3. searchable and externally linkable (e.g., from merge requests and issues)
>>> 
>>> If we need synchronous breakouts, we could do so, but there should be a 
>>> summary back for those who couldn't participate synchronously.
>>> 
>>> Barry Smith mailto:bsm...@petsc.dev>> writes:
>>> 
  I'd like to start a discussion of PETSc 4.0 aka the Grand Refactorization 
 but to have that discussion we need to discuss what tool to use for that 
 discussion. 
 
  So this discussion is not about PETSc 4.0, please don't discuss it here.
 
  What do people recommend to use for the discussion
 
 * dedicated mailing list
 * slack channel(s)
 * zulip channel(s)
 * something else?
 
 I'd like a single tool that anyone can join at any time, see the full 
 history, can attach files, search, not cost more money the we are already 
 paying, etc.
 
 I expect this discussion to take maybe a week and then the actual 
 discussion to take on the order of two months.
 
  Thanks
 
Barry
 
 
>> 
> 

Re: [petsc-dev] Prediscusion of appropriate communication tool for discussion of PETSc 4 aka the Grand Refactorization

[Satish Balay via petsc-dev]

And the monolithic/single issue aka#360 is very slow to access/browse..

Satish

On Fri, 19 Jun 2020, Jacob Faibussowitsch wrote:

> > I think a special GitLab issue (something akin #360 CI Tracker) would do 
> > the job quite nicely.
> I agree more with this. This also allows you to immediately see the list of 
> linked MR’s and issues right in the conversation, as well as being able to 
> link code snippets. One gripe however is that the issue becomes monolithic 
> with multiple conversation threads (as you can see the CI error issue is a 
> totally unstructured Smörgåsbord). To keep a more structured overview we 
> should have multiple issues that are linked together. 
> 
> Best regards,
> 
> Jacob Faibussowitsch
> (Jacob Fai - booss - oh - vitch)
> Cell: (312) 694-3391
> 
> > On Jun 19, 2020, at 12:34 PM, Hapla Vaclav  
> > wrote:
> > 
> > I like Slack but it does NOT have the full history in the free plan - it's 
> > limited to 10k messages.
> > 
> > I think a special GitLab issue (something akin #360 CI Tracker) would do 
> > the job quite nicely.
> > 
> > Vaclav
> > 
> >> On 19 Jun 2020, at 06:48, Jed Brown  wrote:
> >> 
> >> I would prefer this mailing list or GitLab issues because they are
> >> 
> >> 1. genuinely open to external participants,
> >> 2. more async-friendly for those in different timezones and folks with 
> >> young kids, and
> >> 3. searchable and externally linkable (e.g., from merge requests and 
> >> issues)
> >> 
> >> If we need synchronous breakouts, we could do so, but there should be a 
> >> summary back for those who couldn't participate synchronously.
> >> 
> >> Barry Smith  writes:
> >> 
> >>>  I'd like to start a discussion of PETSc 4.0 aka the Grand 
> >>> Refactorization but to have that discussion we need to discuss what tool 
> >>> to use for that discussion. 
> >>> 
> >>>  So this discussion is not about PETSc 4.0, please don't discuss it here.
> >>> 
> >>>  What do people recommend to use for the discussion
> >>> 
> >>> * dedicated mailing list
> >>> * slack channel(s)
> >>> * zulip channel(s)
> >>> * something else?
> >>> 
> >>> I'd like a single tool that anyone can join at any time, see the full 
> >>> history, can attach files, search, not cost more money the we are already 
> >>> paying, etc.
> >>> 
> >>> I expect this discussion to take maybe a week and then the actual 
> >>> discussion to take on the order of two months.
> >>> 
> >>>  Thanks
> >>> 
> >>>Barry
> >>> 
> >>> 
> > 
> 
> 

Re: [petsc-dev] Prediscusion of appropriate communication tool for discussion of PETSc 4 aka the Grand Refactorization

[Jacob Faibussowitsch]

> I think a special GitLab issue (something akin #360 CI Tracker) would do the 
> job quite nicely.
I agree more with this. This also allows you to immediately see the list of 
linked MR’s and issues right in the conversation, as well as being able to link 
code snippets. One gripe however is that the issue becomes monolithic with 
multiple conversation threads (as you can see the CI error issue is a totally 
unstructured Smörgåsbord). To keep a more structured overview we should have 
multiple issues that are linked together. 

Best regards,

Jacob Faibussowitsch
(Jacob Fai - booss - oh - vitch)
Cell: (312) 694-3391

> On Jun 19, 2020, at 12:34 PM, Hapla Vaclav  wrote:
> 
> I like Slack but it does NOT have the full history in the free plan - it's 
> limited to 10k messages.
> 
> I think a special GitLab issue (something akin #360 CI Tracker) would do the 
> job quite nicely.
> 
> Vaclav
> 
>> On 19 Jun 2020, at 06:48, Jed Brown  wrote:
>> 
>> I would prefer this mailing list or GitLab issues because they are
>> 
>> 1. genuinely open to external participants,
>> 2. more async-friendly for those in different timezones and folks with young 
>> kids, and
>> 3. searchable and externally linkable (e.g., from merge requests and issues)
>> 
>> If we need synchronous breakouts, we could do so, but there should be a 
>> summary back for those who couldn't participate synchronously.
>> 
>> Barry Smith  writes:
>> 
>>>  I'd like to start a discussion of PETSc 4.0 aka the Grand Refactorization 
>>> but to have that discussion we need to discuss what tool to use for that 
>>> discussion. 
>>> 
>>>  So this discussion is not about PETSc 4.0, please don't discuss it here.
>>> 
>>>  What do people recommend to use for the discussion
>>> 
>>> * dedicated mailing list
>>> * slack channel(s)
>>> * zulip channel(s)
>>> * something else?
>>> 
>>> I'd like a single tool that anyone can join at any time, see the full 
>>> history, can attach files, search, not cost more money the we are already 
>>> paying, etc.
>>> 
>>> I expect this discussion to take maybe a week and then the actual 
>>> discussion to take on the order of two months.
>>> 
>>>  Thanks
>>> 
>>>Barry
>>> 
>>> 
> 

Re: [petsc-dev] Prediscusion of appropriate communication tool for discussion of PETSc 4 aka the Grand Refactorization

[Hapla Vaclav]

I like Slack but it does NOT have the full history in the free plan - it's 
limited to 10k messages.

I think a special GitLab issue (something akin #360 CI Tracker) would do the 
job quite nicely.

Vaclav

> On 19 Jun 2020, at 06:48, Jed Brown  wrote:
> 
> I would prefer this mailing list or GitLab issues because they are
> 
> 1. genuinely open to external participants,
> 2. more async-friendly for those in different timezones and folks with young 
> kids, and
> 3. searchable and externally linkable (e.g., from merge requests and issues)
> 
> If we need synchronous breakouts, we could do so, but there should be a 
> summary back for those who couldn't participate synchronously.
> 
> Barry Smith  writes:
> 
>>   I'd like to start a discussion of PETSc 4.0 aka the Grand Refactorization 
>> but to have that discussion we need to discuss what tool to use for that 
>> discussion. 
>> 
>>   So this discussion is not about PETSc 4.0, please don't discuss it here.
>> 
>>   What do people recommend to use for the discussion
>> 
>>  * dedicated mailing list
>>  * slack channel(s)
>>  * zulip channel(s)
>>  * something else?
>> 
>>  I'd like a single tool that anyone can join at any time, see the full 
>> history, can attach files, search, not cost more money the we are already 
>> paying, etc.
>> 
>>  I expect this discussion to take maybe a week and then the actual 
>> discussion to take on the order of two months.
>> 
>>   Thanks
>> 
>> Barry
>> 
>> 

Re: [petsc-dev] Prediscusion of appropriate communication tool for discussion of PETSc 4 aka the Grand Refactorization

[Jed Brown]

I would prefer this mailing list or GitLab issues because they are

1. genuinely open to external participants,
2. more async-friendly for those in different timezones and folks with young 
kids, and
3. searchable and externally linkable (e.g., from merge requests and issues)

If we need synchronous breakouts, we could do so, but there should be a summary 
back for those who couldn't participate synchronously.

Barry Smith  writes:

>I'd like to start a discussion of PETSc 4.0 aka the Grand Refactorization 
> but to have that discussion we need to discuss what tool to use for that 
> discussion. 
>
>So this discussion is not about PETSc 4.0, please don't discuss it here.
>
>What do people recommend to use for the discussion
>
>   * dedicated mailing list
>   * slack channel(s)
>   * zulip channel(s)
>   * something else?
>
>   I'd like a single tool that anyone can join at any time, see the full 
> history, can attach files, search, not cost more money the we are already 
> paying, etc.
>
>   I expect this discussion to take maybe a week and then the actual 
> discussion to take on the order of two months.
>
>Thanks
>
>  Barry
>
>   

Re: [petsc-dev] Prediscusion of appropriate communication tool for discussion of PETSc 4 aka the Grand Refactorization

[Junchao Zhang]

A dedicated mailing list has all these functionalities and is easier to see
discussion threads.
--Junchao Zhang


On Thu, Jun 18, 2020 at 9:27 PM Barry Smith  wrote:

>
>I'd like to start a discussion of PETSc 4.0 aka the Grand
> Refactorization but to have that discussion we need to discuss what tool to
> use for that discussion.
>
>So this discussion is not about PETSc 4.0, please don't discuss it here.
>
>What do people recommend to use for the discussion
>
>   * dedicated mailing list
>   * slack channel(s)
>   * zulip channel(s)
>   * something else?
>
>   I'd like a single tool that anyone can join at any time, see the full
> history, can attach files, search, not cost more money the we are already
> paying, etc.
>
>   I expect this discussion to take maybe a week and then the actual
> discussion to take on the order of two months.
>
>Thanks
>
>  Barry
>
>

[petsc-dev] Prediscusion of appropriate communication tool for discussion of PETSc 4 aka the Grand Refactorization

[Barry Smith]

   I'd like to start a discussion of PETSc 4.0 aka the Grand Refactorization 
but to have that discussion we need to discuss what tool to use for that 
discussion. 

   So this discussion is not about PETSc 4.0, please don't discuss it here.

   What do people recommend to use for the discussion

  * dedicated mailing list
  * slack channel(s)
  * zulip channel(s)
  * something else?

  I'd like a single tool that anyone can join at any time, see the full 
history, can attach files, search, not cost more money the we are already 
paying, etc.

  I expect this discussion to take maybe a week and then the actual discussion 
to take on the order of two months.

   Thanks

 Barry