[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 <vaclav.hapla at erdw.ethz.ch> wrote:
> 
>> 
>> On 19 Jun 2020, at 20:39, jed at jedbrown.org <mailto:jed at 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. <https://docs.gitlab.com/ee/user/profile/notifications.html#notification-scope> 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 <vaclav.hapla at erdw.ethz.ch <mailto:vaclav.hapla at erdw.ethz.ch>> wrote:
>> Why not have a separate project within the same group https://gitlab.com/petsc? <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 at jedbrown.org <mailto:jed at 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 <bsmith at petsc.dev <mailto:bsmith at 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 <jacob.fai at gmail.com <mailto:jacob.fai at 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 <vaclav.hapla at erdw.ethz.ch <mailto:vaclav.hapla at 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 <jed at jedbrown.org <mailto:jed at 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 <bsmith at petsc.dev <mailto:bsmith at 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
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20200619/91e12cb9/attachment.html>