Re: Issue Triage 3 May 2023

čt 4. 5. 2023 v 14:53 odesílatel Evan Prodromou <evan@prodromou.name>
napsal:

> Melvin,
>
> That sounds like a solution I can live with!
>
> In the future, I'll include either the full text of the page in the
> comment, if it's short, or a brief summary, if it's long, as well as a link
> to the wiki page.
>

Thanks you Evan, I believe it will greatly assist in connecting the
wiki/primer material with the corresponding issues.

I've added a link from the wiki back to the issue, completing the circle,
to one issue, and will do more if I get time.

These improvements help improve the process going forward. Let's see how
well lit works.

Aside: I think there is some utility of GitHub labels, I'll also point out
this JSON-LD board from W3C:

https://github.com/orgs/w3c/projects/4


>
> Thanks,
>
> Evan
>
> On May 4, 2023 06:57, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>
>
>
> čt 4. 5. 2023 v 12:38 odesílatel Evan Prodromou <evan@prodromou.name>
> napsal:
>
> Hi Melvin. You're very welcome! This process is working because it's clear
> and lightweight.
>
> I've heard what you've said about the wiki, and appreciate your attention
> to detail. However, absent a better option, I'm going to keep using the
> wiki for non-normative documentation and explanations.
>
> The wiki is a w3c tool. We're a w3c group. It's a natural place to make
> sure this content is available to future iterations of this group.
>
> It's a feature that the wiki pages change and are collaborative, not a
> bug. I believe the further explanation of how to identify sub-types made it
> more useful for developers, since there was some confusion on how JSON-LD
> uses types.
>
> I don't think other tools, like comments on GitHub issues, mailing list
> posts, or posts on the Discourse forum are better for this kind of
> documentation.
>
> If you'd like to see those non-normative explanations in the Primer copied
> somewhere else, they are available under an open document license. Please
> feel free to replicate them.
>
> Amy Guy suggested making an ActivityPub primer as a w3c note, which I
> think would be a great idea. If she chooses to do that, I hope the wiki
> pages make a useful starting point.
>
>
> It's evident that you have a preference for working with wikis, and as the
> founder of the well-known site "Wikitravel," this isn't entirely
> unexpected. While I appreciate your contributions and believe a primer with
> W3C Note status could be beneficial, it's important to remember that most
> CGs primarily use mailing lists and GitHub for collaboration.
>
> The current workflow presents some challenges since issues are being
> closed, with resolutions linked to content that might change over time. As
> a result, those following the issue may encounter different answers at
> different times, as we've seen with the subtypes discussion.
>
> To improve this process, I propose the following steps:
>
> 1. When you believe a GitHub issue has been resolved, provide the
> explanation within the issue itself.
> 2. If you'd like to include additional non-normative documentation from
> the wiki, ensure that the link in the issue points to a specific version of
> the documentation.
>
> Closing an issue and linking to content that may not necessarily resolve
> the issue is not an ideal approach. By implementing the above suggestions,
> we can maintain a more effective and transparent workflow for the group.
>
>
>
> Evan
>
> On May 4, 2023 05:48, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>
>
>
> čt 4. 5. 2023 v 1:55 odesílatel Evan Prodromou <evan@prodromou.name>
> napsal:
>
> Hello, everyone. I’m sharing here the list of issues that were triaged
> today.
>
> https://github.com/w3c/activitypub/issues/288
> https://github.com/w3c/activitypub/issues/290
> https://github.com/w3c/activitypub/issues/291
> https://github.com/w3c/activitypub/issues/293
>
> https://github.com/w3c/activitypub/issues/289
>
> I’ll be back to AS2 next week! Thanks to everyone who came.
>
>
> Thank you for doing this. There are some concerns about the current
> process. Transferring closed issues from GitHub to a wiki might be
> problematic due to the following reasons:
>
>    1. Issues are closed and linked to a wiki explanation, while the wiki
>    is not an established part of the group's workflow.
>    2. The content of the wiki may change over time, leading to
>    inconsistencies in explanations for different topics, such as subtypes
>    (last week).
>    3. The wiki, being editable by anyone, might not be a stable source of
>    documentation.
>    4. It's unclear if the wiki genuinely addresses the questions or
>    merely reflects one person's opinion at a specific moment.
>
> While using the wiki as a personal knowledge base is acceptable, we should
> consider a more structured approach. If an issue is closed, perhaps linking
> to a specific version of the wiki page might help, though it could still
> cause issues when the wiki document changes. A more robust process would be
> beneficial to maintain clarity and consistency.
>
>
> Evan
>
>
>
>