search

w3c / activitystreams

Activity Streams 2.0
https://www.w3.org/TR/activitystreams-core/
Other
278 stars 62 forks source link

Don't encourage work-in-progress extensions in w3.org namespace #479

Closed gobengo closed 5 years ago

gobengo commented 6 years ago

Please Indicate One:

Please Describe the Issue:

I see there is a scheduled vote for next meeting on https://github.com/w3c/activitystreams/wiki/Extension-process

I am concerned that it overly encourages using w3.org URLs. Specifically

I really think we should encourage community extensions to be defined on URLs outside of w3.org. There should be a clear distinction of 'work-in-progress' extensions that brand new extension efforts can use and maybe make backward-incompatible changes in all they want. I think these extension URLs should always have some sort of 'group prefix' to prevent over-eagerness to claim good extension names (e.g. https://extensions.activitystreams2.com/work-in-progress/evanp/dating)

Several months or years later, when there is a 'v1.0.0' of the extension promising not to make backward-incompatible changes, the extension effort may want to do a call for implementations and publish an extension URL without the 'work-in-progress' warning. (e.g. https://extensions.activitystreams2.com/dating). At this time, if desired, the old work-in-progress URLs can be HTTP redirected to the final URLs.

Not all extension-authoring groups may have a good, stable place to serve their extension definitions from, so:

I own the following domains and would like to offer them up as a place to define both work-in-progress extensions as well as well-defined and stable community extensions. I will liberally accept group-namespaced work-in-progress extension definitions in their respective git repos:

I'd also support delegating any 'work-in-progress/{groupName}' directory to a git submodule, so innovation can happen in a separate repo unhindered by whoever happens to be in charge of the parent repo (whether w3c or me).

I'd be happy for these repos to not be under my username. Really what I'm proposing is that brand new just-idea, potentially-shifting-under-your-feet, extensions be under /{groupName}/{extensionName} before taking up top-level names.

Additionally, I would help work on a program to build this repo of extensions into a useful website for the community to consume them. e.g. for each extension URL:

I think a plan like this will lead to:

akuckartz commented 6 years ago

:-1:

But I agree that the processes to use the w3.org namespace need to be improved.

sandhawke commented 5 years ago

FWIW, I disagree. Time will tell whether 19 years experience on this issue improves or reduces my judgement. Could well be either. And very, very sorry for not noticing this issue until now.

I think a much simpler, more organic, robust, and low-effort approach is to give out as2 namespace terms on a provisional/experimental basis to any non-harmful extension proposal. That is, someone asks for some terms, and has a rough sketch of what they mean in some web space they can edit but which maintains history and the group / W3C can take over.

If it sees adoption, then it becomes no longer experimental, it becomes adopted by the group, but still probably "unstable". If the group is happy with the spec, it can then become "stable", and maybe eventually W3C Recommended. If it doesn't see adoption it gets retired and the terms can be re-used by someone else later.

Shall I go point-by-point through why I think this is a better approach? I suppose I need to.

(I believe) The CG has very limited capability to affect what URLs like https://www.w3.org/ns/activitystreams/dating actually resolve to, making it unnecessarily difficult to have extensions whose URLs resolve to good human-readable documentation, or even JSON-LD data describing the vocabulary (depending on 'Accept' header of the request)

It's true @rhiaro and I have been terribly slow at updating the document. It's an extremely rusty process, that currently requires both of us, and which ... frankly ... it felt like nobody cared about at all. It's a weakness of mine that I tend to prioritize what it seems like people care about. Also needing both rhiaro and me is clearly a problem -- her part is the HTML bit; see below.

One option is to make https://www.w3.org/ns/activitystreams proxy to somewhere else. That would work if there's someone who's willing to be a better maintainer and everyone agrees to trust sufficiently.

Alternatively, we might be able to streamline the process considerably.

As worded, it encourages a bit of a land grab of good extension names as soon as a project is even envisioned. It shouldn't be uncommon for extension ideas to get started and then abandoned, or started and then take quite some time to be defined and 'published' such that no backward-incompatible changes are introduced. For example, AS2 itself changed 'title' to 'name' or something trivial like this several years after a first draft was published.

The policy has been welcoming of land grabs for some years now, since Lisbon as I recall. Have there been any problems?

In particular, "It shouldn't be uncommon for extension ideas to get started and then abandoned, ..." (I think that's a typo, and you meant "it should be uncommon" or "it shouldn't be common") ... why? What harm does that do anyone? It seems to me like 90% of the harm is to the ego of the person making the proposal, and the rest is the cost of educating the community.

A major win to the as2-namespace approach is that if the proposal gets abandoned by its creator by is liked by someone else, it can be adopted. With the use-your-own-namespace approach, the community is just out of luck if the originator leaves. (You do propose addressing that by making yourself custodian.)

It sounds reasonable to encourage definition extensions in the w3 wiki, but in practice it isn't so easy to either create a w3 account, get access to editing the wiki (see nightpool's experience), manage changes without git/PRs, or learn any given wiki's esoteric syntax

How about github's wiki? You can give edit access to anyone with a github account, and it converts among all common syntaxes (including gfm and mediawiki).

I'd suggest that be the default, but people be allowed to use anything else that's suitably permanent.

There should be a clear distinction of 'work-in-progress' extensions that brand new extension efforts can use and maybe make backward-incompatible changes in all they want.

I don't know what you mean by "backward-incompatible". You mean where they can change the meaning of a term in incompatible ways, like we did with AS2 during development? Sure, any term starts as unstable and becomes increasingly stable. That can be true in the as2 namespace as well. If you make the whole namespace have to be stable or unstable, well, it's a pain, since mistakes happen.

Not all extension-authoring groups may have a good, stable place to serve their extension definitions

Indeed. I think the greatest mistake of the Semantic Web vision was underestimating how hard this is.

I own the following domains and would like to offer them up as a place to define both work-in-progress extensions as well as well-defined and stable community extensions.

How do you propose to handle the situations where you become unable, unwilling, or no longer trusted to act as an appropriate manager here?

I'm quite hesitant to endorse the use of any domain that doesn't have institutional backing, and by an institution with all the right incentives. W3C isn't terribly responsive to change requests for its namespace documents (with or without me in the loop), but at least they're stable and invested in their Recommendations working.

Additionally, I would help work on a program to build this repo of extensions into a useful website for the community to consume them

That would be awesome. I think it could work in either w3c proxy mode, or push-to-w3c mode, if you're willing.

In summary:

Removing incentive to grab top-level extension names

I haven't seen evidence of a real problem here

Faster innovation on work-in-progress extensions

Agreed this is important, but I think as2-namespace + ghwiki + proxy could be quite fast. I'd be comfortable with allowing 'provisional' approval without even a meeting.

Less hangups and debate on Pull Requests into a top-level namespace

Not sure what hangups or debates we're talking about here. In either case, someone trusted needs to be acting as a check on abuse. If we can set it up so that's any of a small group of people, approval could be very quick.

Better trust that extensions defined outside of work-in-progress will be stable, well-thought-out

I'm not really sure what this means. Some extension proposals will be well-thought-out when they first show up, some will need many iterations to become well-thought-out. That's fine. Some great ones will get adoption and advance beyond provisional. Some lousy ones probably will, too.

evanp commented 5 years ago

So, the window is really closing on this discussion. I've been asked by the chairs to get us to a policy ASAP. We can't keep taking up the limited CG meeting time with this issue.

I'd like to continue the conversation about using the AS2 namespace, but define a process for incorporating external namespaces into the AS2 context document. Right now, we don't have a defined way of doing that, which means everyone has to deal with unnecessarily complicated @context structures.

Can we agree on using https://github.com/w3c/activitystreams/wiki/Extension-process for external namespaces, and continue discussions on how and when to use the AS2 namespace?

cwebber commented 5 years ago

I'm good with that for external namespaces. As for AS2 namespaces, I think your approach there is already in the right direction. I think we should look at how XMPP does extensions combined with Evan's suggestions; I think they're doing the right thing by letting each extension define a namespace and write up a specification of how those terms are to be used/behave at the same time.

cwebber commented 5 years ago

Where to publish them is also a valid conversation; as has been noted here the W3C process is currently slow but maybe could be improved. I think something on github is the most likely route to succeed (as much as I hate tying decentralized systems to github). Maybe w3id.org is the right place?

Looking forward to chatting about this, and hopefully getting some resolution on it, on this call.

gobengo commented 5 years ago

In terms of formal consensus, I've voiced my concerns, which seem not to resonate with anyone, which is a-ok with me. Not the first time. And so I have no reason to block anything.

I also value Sandro's opinions generally, not to mention time and thought spent on last response, and think he has proposed some reasonable workarounds.

Given that no one seems to agree with me, heh, then FWIW I'd answer to Evans last question "Yes". And, reviewing it, I'm pretty sure it is quite different than when I filed this issue, and is more better There is no web UI for wiki history I think :'( That it mentions things should have two production implementations before going into main context makes me much happier.

On Wed, Sep 12, 2018, 3:33 PM Evan Prodromou notifications@github.com wrote:

So, the window is really closing on this discussion. I've been asked by the chairs to get us to a policy ASAP. We can't keep taking up the limited CG meeting time with this issue.

I'd like to continue the conversation about using the AS2 namespace, but define a process for incorporating external namespaces into the AS2 context document. Right now, we don't have a defined way of doing that, which means everyone has to deal with unnecessarily complicated @context structures.

Can we agree on using https://github.com/w3c/activitystreams/wiki/Extension-process for external namespaces, and continue discussions on how and when to use the AS2 namespace?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/w3c/activitystreams/issues/479#issuecomment-420670582, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKfBiTTV1tfiB9m5SabO4ObnCMxiQJZks5uaRtWgaJpZM4UqBtQ .

gobengo commented 5 years ago

Beginning of my last comment was authored before I'd reviewed updated wiki page. In fact, I think my concerns must have resonated at least a bit. And in fact the wiki page now reads in a way that the title of this issue has been implemented.

evanp commented 5 years ago

The CG rejected the extension process, so this issue is moot at this point.

sandhawke commented 5 years ago

Does anyone know of anyone who wants any AS2 extensions, someone who would like there to be an extension process?

cjslep commented 5 years ago

I am tracking ForgeFed, ValueFlows, and MoodleNet as potential extensions to AS2.

nightpool commented 5 years ago

mastodon has been implementing lots of general purpose features in our own namespace because of uncertainty with the extension process, and it's stopped us from working on other features

On Wed, Sep 12, 2018, 3:51 PM Cory J Slep notifications@github.com wrote:

I am tracking ForgeFed, ValueFlows, and MoodleNet as potential extensions to AS2.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/activitystreams/issues/479#issuecomment-420775510, or mute the thread https://github.com/notifications/unsubscribe-auth/AAORV3LkmlrHPh2nI_WI12AcphU5GK7cks5uaWXfgaJpZM4UqBtQ .

sandhawke commented 5 years ago

Thanks @nightpool have they been adding them to their own namespace? Can you point me to their specs?

@cjslep Is there anything like a draft spec for some terms yet for any of these? Or just you think they might get there at some point?

nightpool commented 5 years ago

We've been adding to our own namespace, yeah, and no specs so far

On Wed, Sep 12, 2018 at 4:52 PM Sandro Hawke notifications@github.com wrote:

Thanks @nightpool https://github.com/nightpool have they been adding them to their own namespace? Can you point me to their specs?

@cjslep https://github.com/cjslep Is there anything like a draft spec for some terms yet for any of these? Or just you think they might get there at some point?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/w3c/activitystreams/issues/479#issuecomment-420793761, or mute the thread https://github.com/notifications/unsubscribe-auth/AAORV7JGo1GLcNr-8tm_KaI0Zkb6SfYfks5uaXQfgaJpZM4UqBtQ .

nightpool commented 5 years ago

of our current context, the main ones that are namespaced that shouldn't be are toot:Emoji, toot:featured, and toot:focalPoint

sandhawke commented 5 years ago

Looks like the namespace is http://joinmastodon.org/ns but it's not currently resolving?

Is there any documentation at all? A few words saying what 'featured' is supposed to mean?

If not, could you tell me in a sentence, just as an example?

nightpool commented 5 years ago

We have documentation and specs for our client API, but nothing for our server-to-server properties. We don't have a currently hosted namespace, it's just a URI (although it wouldn't be hard to put a document there if it was useful)

  1. toot:Emoji is the most complicated one, it's a resource that's meant to be added to the tag of as2 documents to represent a :shortcode: -> <img> transformation that someone displaying the document can do. this is very conceptually similar to the microsyntax examples in the as2 spec, but for custom emoji rather then users or hashtags

  2. toot:focalPoint is a pair of coordinates representing the "center" of the image for smart cropping algorithms, and it's authored directly by the user (example)

  3. toot:featured is a link to a collection that contains the "pinned" statuses for a given user, which clients can display next on their profile.

nightpool commented 5 years ago

I'm happy to write spec up on them once we have an actual extension process

On Wed, Sep 12, 2018, 5:22 PM Sandro Hawke notifications@github.com wrote:

Looks like the namespace is http://joinmastodon.org/ns but it's not currently resolving?

Is there any documentation at all? A few words saying what 'featured' is supposed to mean?

If not, could you tell me in a sentence, just as an example?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/w3c/activitystreams/issues/479#issuecomment-420802553, or mute the thread https://github.com/notifications/unsubscribe-auth/AAORV5v5LcK7f90a66cP0piAgSRuA4EAks5uaXsmgaJpZM4UqBtQ .