New Inform 7 extensions site

[bg]

@Dannii

The idea is each extension will have a list of maintainers, starting with the original uploader. They can add more maintainers, and you’ll also be able to ask to become a maintainer, to be approved by the librarian (ie Mark Musante).

Does being on the list of maintainers for a given extension just mean you are allowed to make updates and changes, or that you are in charge of making updates? Is it possible to remove oneself from “maintainer” status for a given extension if you uploaded it but it’s not yours?

Another question: I’m not always sure how to apply the tags, e.g. what sorts of extensions count as “adaptive prose,” which ones count as “input,” and so on. Would it make sense to attach descriptions to some of the more ambiguous tags? (Although I have a similar confusion with some of the categories in the existing public library, so maybe it’s just me.)

[Dannii]

HanonO, I do want all the extensions updated, if you’d like to help that would be great

bg, the list of maintainers would just be all the people who can update the extension. As an editor you can already do that for every extension already

On tags, just use what you think is best. It would be possible to add descriptions in the future, but I think most of them are self explanatory. If you think they’re ambiguous feel free to change them if you can think of less ambiguous synonyms.

[bg]

Ok, thanks.

Another question: what should we do about existing extensions that don’t have a date in the version number? There are at least two or three in the public library that don’t. Should we contact the extension authors and ask them to add dates? That might not make sense, though, for old extensions that are no longer in use. Should we just put in a bunch of zeroes?

[Dannii]

When I added the built in extensions from 6G60, 6L02 and 6L38 I used the date I7 was released for the unversioned extensions. I’d do the same for other 6M62, and if you can find a date for anything in the PL great, otherwise just pick today’s date.

Requiring full version numbers is a change from how we’ve done extensions in the past, but it will make extension updates so much easier going forwards.

[bg]

@Dannii

if you can find a date for anything in the PL great, otherwise just pick today’s date.

Ok, yeah, I forgot that on the PL site there’s a “last modified” date.

Thanks!

[matt_weiner (matt w)]

Wow, awesome! Good to see you all working on this!

If I can offer a couple suggestions:

1. The downloading process looks a little cumbersome right now. I go to the front page and click on the Common Commands Sidebar link (for instance) and that takes me to a page with a download button, but if I click on that it takes me to a page with the source code in plain text (I’m using Firefox). From my dealings with Github I know (because someone told me) that right-clicking on the download link and choosing “Save as” will get me the .i7x file in ready-to-install form… but this seems like the sort of thing that puts newbies off. It’d be good to have a dedicated download button, preferably one that shows up even for the front page.
2. Seems like it’d be nice to have an “Every single extension” page–maybe one listed by title and by author, like the Inform7.com page. Right now, you basically have to search and there’s no way to browse extensions if you don’t know the title you’re looking for–am I right?
3. And I guess, are we going to have tags for things like “needs updated,” “good to go,” “dangerous! handle with care”? That might just be a question of making sure we tag everything conscientiously.

Again, great work! Dannii, I’ll PM you once I figure out what my Google account is.

[zarf (Andrew Plotkin)]

It’d be good to have a dedicated download button, preferably one that shows up even for the front page.

Might want to have separate urls for the same content, one with “Content-Disposition: attachment”, one with “inline” (the current behavior).

(Maybe add “?display=true” as an argument to get the inline version?)

[Dannii]

If you open the download link to show the source code, and then go to Save As, does it give you all the right filename? I’m sure I had that working previously, but now in Chrome it doesn’t work, and it puts the filename as 132422.txt or whatever.

[bg]

@Dannii

If you open the download link to show the source code, and then go to Save As, does it give you all the right filename? I’m sure I had that working previously, but now in Chrome it doesn’t work, and it puts the filename as 132422.txt or whatever.

If I right click the “Download” button and then click “Save target as” from there, I get the correct file name and type.

If I click through to the source code, and then right click on that, and then click “Save as,” I get a filename of just numbers, with the text document file type.

[matt_weiner (matt w)]

Belatedly, I’m in mostly the same boat as bg in Firefox–except once I’ve clicked through to the source code, the only “Save as” option is to save the web page, which I’m assuming will give me a webpage.

Also, I haven’t got access to the main page yet, but I updated Disambiguation Control for 6M62 (at least, it runs), so if someone can upload it that would be great! I think this version should be back-compatible through 6L02 if it works at all. (All I did besides versioning was change things like “if the number of entries in L is 0, yes” to “if the number of entries in L is 0, decide yes” in a lot of places, and also change Jon’s e-mail address to mine, since I don’t think he has any interest in feedback on this extension anymore.)

[bg]

Do we want to be able to make notes or tags for specific versions of extensions? For instance, Flexible Windows was, I think, in the public library at some point. But recent versions of FW are not in the public library, because it’s in the process of being rewritten or re-documented. Is there a way to indicate which versions are/were considered “complete” and so were in the public library, and which versions are considered in-progress?

@matt w

I updated Disambiguation Control for 6M62 (at least, it runs), so if someone can upload it that would be great! I think this version should be back-compatible through 6L02 if it works at all.

Ok, I’ve uploaded your version, and marked it for 6M62 and the two 6L builds.

[matt_weiner (matt w)]

@bg

Do we want to be able to make notes or tags for specific versions of extensions? For instance, Flexible Windows was, I think, in the public library at some point. But recent versions of FW are not in the public library, because it’s in the process of being rewritten or re-documented. Is there a way to indicate which versions are/were considered “complete” and so were in the public library, and which versions are considered in-progress?

Yes, IMO this would definitely be desirable. It’d be good to host multiple versions of extensions; at present some old versions are housed at the inform7.com old extension site, but we should plan for extensions that stop being back-compatible with older versions of Inform,* and it’d be nice to have the capacity to host those old extensions anyway. And we definitely need some way of tagging the ones that are incomplete. So, yes yes yes.

*For instance, if I ever update Actions on Groups, it won’t be back-compatible to 6L, because part of the update will involve telling it how to work with the multiple action processing rules.

[bg]

(Rereading a post at the beginning of this thread)

@Dannii

When uploading extensions it currently tells you that they need to meet the extension guidelines, but that is really only for those which are to be marked as Approved. (The idea is that if the site is loaded from within an IDE the search results would be limited to those which are approved.) The wording could be clarified to say that the guidelines are recommended for all but only required for approval.

I haven’t seen the “approved” designation on the site, but it sounds like it could be applied to individual versions of a given extension–is that right?

Do we need more designations than “approved” and “unapproved”? It seems like unapproved extensions could fall into a range from “utterly broken, I never got this to work at all” to “polished, tested, and works great, but I didn’t feel like adding it to the public library because I don’t want to support it.” But maybe that sort of thing could be in the source text of the extension, and we don’t need to get that specific on the site itself. I’m not sure what makes the most sense.

[Dannii]

I haven’t seen the “approved” designation on the site, but it sounds like it could be applied to individual versions of a given extension–is that right?

Do we need more designations than “approved” and “unapproved”? It seems like unapproved extensions could fall into a range from “utterly broken, I never got this to work at all” to “polished, tested, and works great, but I didn’t feel like adding it to the public library because I don’t want to support it.” But maybe that sort of thing could be in the source text of the extension, and we don’t need to get that specific on the site itself. I’m not sure what makes the most sense.

The approved status shows up as a green tick on the extension’s page: i7el.herokuapp.com/extensions/g … mily-short

Only extensions as a whole are approved, not individual versions.

Now we could add something like that in the future if needed, but I don’t really think it is. If for some reason you have to upload a version of an extension which you know is buggy, the thing to do would be to not select any compatible I7 releases for that update. Once you’ve fixed the bugs you can upload again and select an I7 release. All versions are shown in the versions list, but only the highest version with a compatible I7 release is shown on the main extension page.

And similarly, if you discover a major bug and can’t immediately fix it, the recommended thing would be to unmark it as compatible, so that the download button goes to the last safe version.

Do we want to be able to make notes or tags for specific versions of extensions? For instance, Flexible Windows was, I think, in the public library at some point. But recent versions of FW are not in the public library, because it’s in the process of being rewritten or re-documented. Is there a way to indicate which versions are/were considered “complete” and so were in the public library, and which versions are considered in-progress?

FW was on the old extensions site, but never in the PL (it didn’t exist yet.)

Again, my suggestion would be to only mark an extension as compatible with an I7 release if it’s ready for the public to use. If you’re confident a particular version is sufficiently stable and bug-free then I’d say you could upload it and mark it as compatible if you want to even if you’re continuing to develop it.

I’m not saying we can’t add more status indicators in the future, but I don’t want to overburden us with them if they’re not really necessary.

Ok, I’ve uploaded your version, and marked it for 6M62 and the two 6L builds.

I noticed you made the discussion link go to this forum: viewforum.php?f=7

Is there a specific topic for it? Otherwise it would probably be better not to have the link IMO

[zarf (Andrew Plotkin)]

If for some reason you have to upload a version of an extension which you know is buggy, the thing to do would be to not select any compatible I7 releases for that update.

Not sure that’s enough.

If you want to say that “compatible with Inform release X” really means “approved for public use for Inform release X”, that’s fine. But then the checkmark doesn’t mean anything.

[Dannii]

Not sure that’s enough.

If you want to say that “compatible with Inform release X” really means “approved for public use for Inform release X”, that’s fine. But then the checkmark doesn’t mean anything.

Are we wanting to take on the role of evaluating extensions as a community, or will we leave that for the I7 librarian team? I was more under the impression that for the moment the community just wanted a single place to point people to for the latest versions of extensions.

If that’s the purpose for using the site, and if the site will be based on self evaluations, then I think the I7 release compatibility list is sufficient. And if that’s all the site remains for now, then the checkmark isn’t really useful. If it’s confusing I will hide it. I could also make the compatibility list editing page more explicitly state that you are confirming which I7 releases you have tested the extension with?

If/when the I7 librarians would like to use this site, then we can implement whatever evaluation system they want. If they want to check each update, a la the Apple app store, then approval will have to move to a per version basis.

[bg]

@Dannii

Is there a specific topic for it? Otherwise it would probably be better not to have the link IMO

Ok, I’ve removed it.

@Dannii

FW was on the old extensions site, but never in the PL (it didn’t exist yet.)

“Public library” probably wasn’t the right choice of words. Mostly I meant it was on the Inform site and available for public use. I’m guessing there was some sort of approval process in place to decide if extensions were ready to go on the Inform site, but maybe not.

Re: the other stuff: I want to confirm if I’m understanding correctly. Before you put together this new site, there were, as far as I know, two main public places where extension authors were submitting extensions: the public library, and the I7 extension repo on Github. Reasons for putting an extension on Github but not in the public library seem to vary (from “I never finished it” to “I don’t want to support/maintain it”), but it’s ultimately the author’s choice.

If I’m understanding correctly, uploading an extension to the new site and choosing an Inform build is equivalent to the author saying “this is ready to submit to the public library” (with the understanding that, as of right now, this new site is not official, and not integrated with the PL, and there’s no one approving anything).

And uploading an extension to the new site and not choosing an Inform build would be the equivalent of putting it on Github, but choosing not to submit it to the public library (for whatever reason). Is that right?

If so, then yeah, I think it’d be good to clarify on the site itself exactly what it means to select a Inform build.

And if, for right now, we’re just putting recent versions of extensions on the site, hopefully we won’t run into too many situations where we’ve got different versions of the same extension that are compatible with different Inform builds. (If we did run into situations like that, then the Inform builds selected wouldn’t apply to all the available versions of the extension).

[Dannii]

If I’m understanding correctly, uploading an extension to the new site and choosing an Inform build is equivalent to the author submitting it to the public library for approval. And uploading an extension to the new site and not choosing an Inform build would be the equivalent of putting it on Github, but not submitting it to the public library (for whatever reason). Is that right?

Public Library extensions need to meet higher standards than those of author supported extensions: they need to be fully documented, have tests/examples, have only named rules, only depend on public library extensions, and probably more. So it’s very possible to have an extension which you want to support, and you want to say which I7 builds it’s compatible with, but which you can’t yet submit for public library approval, and if that’s because it depends on another extension which isn’t approved, the reasons why you couldn’t submit it aren’t even in your control.

[bg]

@Dannii

If I’m understanding correctly, uploading an extension to the new site and choosing an Inform build is equivalent to the author submitting it to the public library for approval. And uploading an extension to the new site and not choosing an Inform build would be the equivalent of putting it on Github, but not submitting it to the public library (for whatever reason). Is that right?

Public Library extensions need to meet higher standards than those of author supported extensions: they need to be fully documented, have tests/examples, have only named rules, only depend on public library extensions, and probably more. So it’s very possible to have an extension which you want to support, and you want to say which I7 builds it’s compatible with, but which you can’t yet submit for public library approval, and if that’s because it depends on another extension which isn’t approved, the reasons why you couldn’t submit it aren’t even in your control.

Okay, it sounds like you’re saying that, if an extension on the new site is marked with an Inform build, that means the extension is (in the extension author’s opinion) ready for public use, and supported, but it may or may not meet public library standards. So as of right now, the new site makes no distinction between usable (in the author’s opinion) extensions that are in the public library, and usable (in the author’s opinion) extensions that aren’t in the public library.

And putting an extension on the new site, but not marking an Inform build, means that it’s either not ready for public use, or not supported.

Am I following you correctly?

[Juhana]

I’ve followed the conversation only summarily so apologies if this is repetition or if I’m suggesting something that’s already being planned or rejected as a bad idea.

Right now the extension system as a whole leaves newcomers (and others too) confused for a good reason. Between the inform7.com extension site, which in theory hosts extensions only for 6G60 and earlier (although in practice I think some of them have been updated), the Public Library, which is accessible in practice only through the IDE, and the Github repository, for someone who’s just getting to the point where they start to learn about or need extensions it’s not clear at all what these places do, why there are so many of them, and which one to use, especially if each of them has a different version of an extension they want. (We probably all know this and agree that it’s not an optimal system.)

What my expectation for the new site is that it would clear up the confusion in one clean stroke and that it would be primarily aimed at providing currently up-to-date extensions. Everything from inform7.com and the Public Library would be moved to the new site, and everyone would be directed to use the new site. The inform7.com extension page would just link to the new site, the Github repository readme would have a big disclaimer that it’s primarily for extension development and experimental extensions only, and emshort.com/pl/ (where the IDE pulls the Public Library content at the moment) could be either replaced with the new site, or a script would automatically generate the Public Library based on what’s in the new site.

This in mind, when you visit the new site, it should show by default only the extensions that are compatible with the latest version of Inform. I don’t think newcomers should need to know or care what their Inform version is other than that it’s the latest. If I look at the site from a beginner’s point of view, it’s not at all obvious what “Version 10/170416 for Inform 7 6M62, 6L38, 6L02” means. Even as a “pro” user I would rather only see the extensions that are compatible with the version I’m currently using, instead of having to manually search for the correct version number in the list. There could be a dropdown menu in the navigation bar where you could choose from a list of I7 versions (defaulting to the latest), and that would change which extensions are shown (e.g. if you choose 6G60 you only see extensions compatible with 6G60), including a “show all” option if you really want to see everything regardless of compatibility.

What I don’t see useful is for the new site to host broken or incomplete extensions. The Github repository is ideal for that purpose. If the new site does need to host these kind of extensions, they should be hidden by default and the option to show them should be buried somewhere where it’s not possible to accidentally display them. Otherwise it’s just asking for more confusion and angry forum threads about how the I7 ecosystem is broken.

Anyway, this looks really good already and I’d be happy to help implement this stuff if people think it’s a good idea. I’ll have a preview out of a Big Project at the end of the month (hype! hype!) but once that’s in a good shape I could take a closer look at this one.