repo name nit: it'd be nice if this were simply w3c/epub

[hober]

(or w3c/epub3, given w3c/epub4 also exists)

[mattgarrish]

I was going to suggest the epub4 repository could just be deleted as we never used it, but then I discovered all the neat stuff it does...

No strong opinion one way or the other on changing repository names. The diffs and revision histories cited in the older revisions broke ages ago when we moved off google code and then changed a bunch of labels, so I can't imagine it could make things any worse.

[iherman]

1. We can do neat stuff elsewhere 😀, so deleting, or at least archiving, the epub4 repository is fine with me. I do not see us reopening the epub4 line in the years to come...

2. My worry with the epub-spec->epub renaming is twofold.

   1. I hope that the GitHub redirection will continue to work, but I am not sure about github.io/epub-spec. If those types or URLs are not redirected, we will create a bunch of dangling links in our specs, because all the editors' drafts have those types of URLs. Usually, having dangling links in /TR documents is a big no-no...
   2. Don't we create (false) expectations for the epub repository? Wouldn't people expect to find outreach documents, presentation materials, discussion papers, etc., all related to the present and future of epub? That expectation will not be fulfilled, because such documents do not really exist at present. The only thing the repository stores are, well, epub specifications…

   At this moment, I'd prefer not to make the change. The possible set of troubles does not seem to be worth it.

[mattgarrish]

I also seem to recall we changed from the original "epub-revision" name from the idpf days to "epub-specs" because we added "epub-tests" and didn't want too generic a name. That's why I'm fine either way on this.

[mattgarrish]

I wonder if it would be useful to create a w3c/epub repository and use it as a directory to get to all our other repositories? (epub-specs, epub-tests, publishingcg, publ-a11y, etc.) We'd probably just want to disable issue creation.

Otherwise, we should probably close this issue.

[iherman]

Do you mean a repository with a single readme file pointing at the other repositories? I am not sure I would add anything more than the epub-specs and epub-tests; the cg may do other things, so can publ-a11y. Ie, the latter two may go beyond epub at some point.

We could also put an explicit reference to the epub overview document.

It is doable. Is it worth it?

(How do I disable issuing?)

[iherman]

(The epub4 repo has been archived in 2022; if touch all these things, I would be in favor deleting it...)

[mattgarrish]

Do you mean a repository with a single readme file pointing at the other repositories?

Ya, make it a directory page. You can turn off the issues tab in the setting tab.

the cg may do other things

Sure, but the description for them could say as much. It's still where a lot of epub-related discussions and work go on.

Is it worth it?

That was my question. You can't ask it back at me... 😉

[iherman]

That was my question. You can't ask it back at me... 😉

Why don't we ask our fearless chairs? @wareid @sueneu @shiestyle ?

[sueneu]

I wonder if it would be useful to create a w3c/epub repository and use it as a directory to get to all our other repositories?

As the newbie, I would love to have a single place I can go to find links to all the other repositories.

How to maintain it going forward is worth thinking through. Especially if we disable issuing. Working Groups building new repositories would need a way to add to the directory.

Is it worth it? I am not familiar enough with Github to know how much pain is involved in making or maintaining this.

[iherman]

I wonder if it would be useful to create a w3c/epub repository and use it as a directory to get to all our other repositories?

As the newbie, I would love to have a single place I can go to find links to all the other repositories.

How to maintain it going forward is worth thinking through. Especially if we disable issuing. Working Groups building new repositories would need a way to add to the directory.

That is no problem. I presume disallowing issues makes it still possible to commit new versions of the readme file

Is it worth it? I am not familiar enough with Github to know how much pain is involved in making or maintaining this.

Making is easy and quick. Maintaining should not be a big deal either.

[mattgarrish]

I presume disallowing issues makes it still possible to commit new versions of the readme file

Right, all it does it take away the issues tab so no one can create new ones. It doesn't otherwise affect the functionality of the repository (that would be archiving the repository where everything is disabled).

Given the limited scope of what the repository would be for, I don't think we need to allow issues. It just invites people who aren't paying attention to open issues there that belong elsewhere.

And other working groups could either edit the readme directly if they have group rights to modify files or open pull requests to include additional text.

[shiestyle]

I have no opposition to add w3c/epub repository as a top directory.

[iherman]

Created https://github.com/w3c/epub, and there is a PR https://github.com/w3c/epub/pull/1 for the content of the readme page.

@hober I hope that works for you.

(This issue will be closed if https://github.com/w3c/epub/pull/1 gets merged.)

[iherman]

https://github.com/w3c/epub is now alive with pointers elsewhere. Closing.