View in #core on Slack
@jnylen: Meeting here in 10 minutes to discuss the following:
- Version 1.1.0 planning and progress
- Plugin and theme directory planning
- Open floor
@viktor608: Highly exciting! 
@jnylen: !channel ClassicPress core development meeting starting now, whoās here? 
:skin-tone-2:
@tim.kaye: Iām here!
@ALS:
@will:
@raygulick: 
lurkingā¦
@blueskyphoenixllc:
@mte90net: 
@elisabetta.marina.cle: 
@slack1596: i think iām somewhere
@manfred:
@slack1891: @slack1891 has joined the channel
@dev062: lurking
@jnylen: As people are coming in, if you havenāt read https://www.classicpress.net/blog/2019/06/27/classicpress-development-update/ yet then I would recommend doing so
@slack1891:
@jnylen: that post is still a good update about where we are now and where weāre headed
@norske:
@jnylen: so, Iām basically just going to go through https://github.com/ClassicPress/ClassicPress/milestone/11 (our list of issues for version 1.1.0) and talk about the status of each item
first, https://github.com/ClassicPress/ClassicPress/issues/414 and https://github.com/ClassicPress/ClassicPress/pull/431 (same issue), thanks @norske for working on this.
[ClassicPress/ClassicPress] #414 Theme update notices may be cut off
[ClassicPress/ClassicPress] #431 Fixed theme update notices (overlapping, fixed height and excessive length)
I havenāt had a chance to test this out yet, but I donāt see any further issues from looking through the code.
If anyone has a development installation and can test out this change, that would definitely be helpful!
If this is something youād like to do but arenāt sure howā¦
I think this is another thing we need a tutorial for 
Iām going to try not to get into that too deeply right now, but the basic steps are to clone the ClassicPress git repository to your computer, turn that into a working site using your favorite server software, and then check out the branch for the PR youāre going to test
Several of us, myself included will be happy to answer questions about any of that here
Computer issues here, just a momentā¦
Alright, next up is https://github.com/ClassicPress/ClassicPress/pull/397
This is intended to fix an error that says āInvalid archive structureā when upgrading ClassicPress. Iād like to look at our server logs to find out how common it is, and decide whether to include it in the release based on that.
@will: This on looks to have minimal reach, I would be hesitant to put any workaround in place and rather we push upstream to resolve on the linked requests repo.
@jnylen: A full resolution of this issue in the upstream library would be much more difficult.
A better alternative on our end would be to tell people to install libcurl for PHP on their servers.
@will: The code in the PR looks like it does resolve the issue however the error reporting should be swapped to something more filterable.
Aside from my preferences that this be resolved upstream I see no other blockers to actually merging this in.
@jnylen: We donāt have to merge it, because even without the error_log it is still a hack 
@will: Letās assess the impact on users before deciding?
We still have a bit of time before we need a decision.
@jnylen: yes, thatās my thinking also, so Iāll look in the logs for our upgrade API server
@tim.kaye: Could we just have an FAQ that users could be directed to if they experience this problem? Then they would see that they need to install libcurl.
@jnylen: hopefully this is a very infrequently asked question, but yes, that would be another solution
@tim.kaye: OK, an IAQ!
@raygulick: Questions you never thought to askā¦
@will: I am curious if other parts of core are affected by this same problem. Are there other places we may make the same kind of file download requests?
@jnylen: this issue may reappear once we start serving plugins from GitHub in v2
I am not sure what criteria GitHub uses to decide whether to serve files in chunked mode
wordpress.org apparently does not, likely because of this issue
@norske: There are other curl dependencies across the code, it seems. So it might be a basic hosting requirement. In that case FAQ item is enougth.
@jnylen: WP/CP is supposed to be able to use other transports for HTTP
as far as I know, that works, apart from this issue
we might also want to require curl for v2
would allow for some nice code simplifications, the HTTP code is very messy
@norske: neet to look through class WP_Http_Curl I think
@jnylen: ok, so this one needs some further investigation
I am also not convinced the fix in that PR is a great idea, HTTP/1.0 is ancient
@slack1596: libcurl would be useful in other areas too
e.g. if we want to easily validate weāre talking to the plugin dir we can have our own CA
canāt do that without libcurl
@norske: btw, there is a hook āuse_curl_transportā, maybe it could help it somehow
@jnylen: we would probably remove that hook (and a bunch of other related code)
@norske: ok, i think tht curl is a requirement then
@jnylen: if we make curl a requirement *
@norske: so fix is ok
@fwolf: woops. just seen this.
@jnylen: right now I am thinking that requiring curl for v2 is the best path
ok, moving onā¦
https://github.com/ClassicPress/ClassicPress/issues/422
(improve the changelog display in the ClassicPress dashboard - right now it doesnāt really show what has changed from WordPress, or in the last few versions of ClassicPress)
I propose that we pull this information from the GitHub releases pages
@will raised a concern there about making frequent API requests, but I think we can address this by using a transient with a long lifetime. William (and others) do you agree?
@ALS: ClassicPress News widget too, please.
@jnylen: The main reason to do it this way is to avoid having to put the changelog information in 3 places instead of 2 like we have today
@ALS: The first item is The Month in WordPress: June 2019
@jnylen: hmm, @ALS this is probably because we didnāt change the transient name from what WP used
that should be an easy fix - can you create an issue on GitHub with a screenshot?
@ALS: Youāre making me register a GitHub account after making me register for Slackā¦ The things I do :rolling_on_the_floor_laughing:
@elisabetta.marina.cle: @ALS git is a necessityā¦
@ALS: Discussion for another day in random :rolling_on_the_floor_laughing:
@jnylen: Coming back to this specific question, I think it is well worth it to avoid introducing more extra steps into the release process. Automate as much as possible
[July 1st, 2019 11:36 AM] jnylen: <@UKJSXMTJP> raised a concern there about making frequent API requests, but I think we can address this by using a transient with a long lifetime. William (and others) do you agree?
@mte90net: a transient is the best way
@will: Some form of long lived cache satisfies my concerns.
@fwolf: transient, maybe once a day or all 12h?
@jnylen: even once a week or month would be fine I think
@norske: optional
@fwolf: add a setting 
@norske: different need for me and my end clients as exmple
@jnylen: @norske Iām not sure what you mean?
@norske: CP news and other internal events are interesting for dev, but not for dev clients. It would be nice to have a setting for enabling nd frequency
@fwolf: oh noes. a setting for a transient
@jnylen: so, I am talking about the Whatās New page under the About section of the dashboard
@fwolf: what have I done! 
@jnylen: there was another issue brought up which is separate
@norske: ok, I might be messed by translation, keep on please
@jnylen: the dashboard widgets can be re-configured in different ways using existing filters, I think that is something we could document (and add another hook if necessary) but this would be better done in a mu-plugin
I would suggest creating an issue or a forum thread about that use case
one more issue for v1.1.0 (that I just created during the course of this meeting): https://github.com/ClassicPress/ClassicPress/issues/433
when you migrate from WP to ClassicPress, the upgrade routine removes some files that we know were included in WP 5.x but not in ClassicPress
with newer versions of WP, there are some more files to remove, so that issue is to identify them and add them to the ClassicPress code for removal
@ALS: Like? Sorry. Curiosity.
@elisabetta.marina.cle: Like the gb bloat?
@jnylen: Iām not sure, because I havenāt looked yet, but yes, they would be Gutenberg-related files
So, both of those last two issues in our 1.1.0 milestone ( https://github.com/ClassicPress/ClassicPress/milestone/11 ) are marked as help wanted because they have not been started yet (changelog display and extra files on migration). If you are interested in helping then please leave a comment on GitHub, submit a pull request, or ask questions here.
A couple of other relatively minor things have come up in this meeting that Iād be happy to include in 1.1.0 also, as long as they get reported and fixed in time for the release. (Fixing the ClassicPress news widget on migration, and new hooks if needed, or at least better documentation on how to modify the existing dashboard.)
Aside: Documentation is a whole other topic, we also need someone to help unify and clean up our existing documentation which is spread out across several different places. This would be a topic for separate discussion in docs
Next item on the agenda was discussion of the theme and plugin directory.
Quick recap of the current status, itās in planning, mostly in the plugin directory subforum: https://forums.classicpress.net/c/plugins/plugin-directory
ClassicPress Forums: Plugin Directory
Also the brief outline of the planned structure, from last weekās blog postā¦
https://classicpress.slack.com/archives/CDUSG982W/p1561889812026400
[June 30th, 2019 3:16 AM] will: So tomorrow is the next core meeting. During it I would like to bring up and discuss the future of theme in CP. We can most certainly extend the work for plugins directory to themes as well so we might be about to get a jumpstart for themes directory and start hacking away on it this coming week.
@will: With relation to the theme directory I have a proposal with I do not think we have took go through today as we are nearly at the 1 hour mark.
@jnylen: I am happy to continue discussing that here, if others need to run thatās fine, the chat history will be here later too.
@will: I have time to volunteer and experience to share when it comes to building a similar experience for themes as there is for plugins.
@slack1596: so far 99% of the work has been on the backend technical details - itād be nice to see some ideas for the UI/UX
@will: Essential Iām offering to focus on the themes side and allow us to build concurrently so we can benefit for successes on each side.
@ALS: We really need a CP default theme 
@jnylen: Hopefully we can re-use most of the same infrastructure for plugins and themes. No doubt the UI pieces would be different, Iām more thinking of the backend APIs and such there.
@ALS: I know this relates more to the theme directory
@will: Themes side my needs are simple - 1 CPT, 2 taxonomies, 4 custom metas. I believe I can make a directory listing from GitHub submissions from that.
@ALS: But a default theme is super important for branding.
@jnylen: so, we should not plan to build the plugin and theme directories using ClassicPress as a base
instead, we should be looking for something more like the way our core updates API currently works (a set of JSON files that are served statically and updated when needed)
@will: I strongly suggest we do base on CP. Without it we build from scratch which may take months. I was hoping to have a PoC within 4 weeks for itteration.
@jnylen: there is almost no overlap between what CP can do and what we need this software to do
it is also very difficult to secure this way, especially since we will need many users with limited access
@will: It is a CMS and I want to manage content. Iām sure I can make it work quite well within CP.
If you know of an alternative I can simply start work immediately with that would be great but I would like to build CP features with CP.
@slack1596: weāve had a long technical discussion about this elsewhere - CP isnāt a suitable choice for the core directory
@jnylen: The fundamental design of ClassicPress is that users enter content via an editing interface, which is stored in a database and mapped to a set of URLs. Then you can (mostly) independently change the design of the site while keeping that content the same.
Whereas the source of the content for a plugin is so different from the way a page gets its content in ClassicPress, it would actually end up being more work to bolt something on to CP, and much slower and clunkier (those are important also)
I do have an alternative proposal.
- start with a list of plugins/themes (there are several examples of each floating around on the forums)
- build some static JSON files for their basic information and host them somewhere
- write a ClassicPress plugin that knows how to read those JSON files and install the plugins
- ā¦ (ābuild the rest of the thingsā, but this would at least get us to a workable starting point)
@fwolf: which is how I would go about it, too.
@jnylen: One notable piece that is not included here is the web interface for viewing and submitting plugins/themes. I imagine us using Laravel or similar for this, but a ClassicPress site would also be a workable prototype.
@will: Batch processing and static analysis runs into Tide scale problems where things become much too complex to easily maintain.
I do not see how I could reach a PoC with that method starring from scratch, building the task runner/scheduler and then also building out a seporate frontend.
@fwolf: Iād use CP for the GUI, and a stand-alone something for the rest, all hold together with some glue
@jnylen: Iām imagining the PoC would be (on the backend) not much more than a list of JSON files that are manually updated.
This approach obviously wonāt work for everything (like search), but I think one file per plugin wouldnāt run into many scaling issues?
@will: Iām not keen to manually generate any JSON files for it as that could be a rabbit hole and thankless task.
@slack1596: actually, iāve been thinking about search - itāll work fine if we use something like Solr (not Solr because Java) as long as weāve got inotify or similar
@jnylen: So far, @slack1596 and I have been the people most involved in the technical planning of this thing. @will if you are able to get involved in building a prototype then that would enable us to get something workable out there much sooner.
@will: If someone else could handle some early backend stuff then maybe I will focus elsewhere for the moment?
@jnylen: Having something working in CP could also be a good path, with the possibility of extracting the important bits out into a stand-alone system later on.
@will: Iām not sure the ideas you mention are what I would see as ideal but Iām willing to let you show me what you mean before I actually suggest an alternative may be better. I dint want to decide without fully understanding so to speak.
@jnylen: The way I see it, there is maybe a 2% overlap between what ClassicPress can do and what we need the plugin directory to do, and that overlap is mostly in the form of displaying webpages based on a template + some individual content that changes per page.
There are also data structures such as CPTs, but theyāre not really the right ones for what we need to build.
@will: My initial thinking was that existing CP content management functions could be used for data storage, that could be processed via timed Cron or (or something more full proof) to update from GitHub. That data for then become static JSON for serving but I did thing pulling into CP initially is the simplest approach.
@slack1596: what are you polling with cron?
@will: Developers could submit their theme/plugin and that submission becomes a CPT, then we fetch the data (and store it in a database and not a filesystem backed cache).
For Cron I expect we use system Cron, no?
@slack1596: possibly, but what for? what are you polling?
@will: GitHub feeds
@slack1596: no need - weāll be using webhooks
@jnylen: Or set up webhooks so that we get notified when things change.
We may not be able to guarantee that every plugin will add a webhook and keep it there though.
@slack1596: we need that as part of the registration process
@will: Webhooks need developers to do extra work. Why require that extra step when it is not needed at outset?
Also webhooks are subject to DDoS style exploits. I wouldnāt suggest we accept directly to the directory we host.
@slack1596: theyāre no more subject to ddos than anything else weāre building
@will: A tasker for outbound pings is less subject to an inbound overflow.
@slack1596: no, because then weāll run into scaling issues polling 50k git repos
@will: I vote we ping out rather than accept webhooks in.
@slack1596: if we canāt secure a simple webhook weāve no business doing any of this anyway
@will: Ok then you suggest we just stop?
@jnylen: I think polling is fine for a prototypeā¦
@will: I see no webhook accepting system already build for this. I am willing to build a polling system.
@jnylen: GitHub API rate limit is 5000 requests/hour, this will scale until we are in production
@will: @slack1596 if you build the system to accept webhooks I will avoid building a polling system and use yours.
That would save a lot of time for me
@slack1596: for now just go with @jnylen plan of having a static hand-rolled json file - that removes the core directory as a blocker
@will: Will you hand roll the JSON? I will not, it is a thankless task for zero gain.
If you do it I will use it.
@jnylen: A workable alternative for a prototype would be a REST API endpoint, knowing that we will probably turn the results into a static file later in the process
Iām not keen to write JSON by hand either - I would build a script to do that
But, realistically, I wouldnāt be able to start on any of this for another month or two
So Iām happy to have help even if itās not in the exact way we had been envisioning it, that doesnāt really seem fair to me
For background, our existing process for core updates is https://github.com/ClassicPress/ClassicPress-APIs/blob/e4f37dcb95f3a84d674051cc24027013243a34d7/v1-upgrade-generator/generate-upgrade-json.py
This script generates JSON files based on git tags, and this kind of approach has a number of advantages around security and performance
@will: Iāll look at your generator script. I can use that once I have the data but I need to get the data once.
@jnylen: For plugins and themes this would look different
@slack1891 and @classicpress196 have an initial list of plugins (their own, with a focus on ClassicPress), and @zulfgani has an initial list of his themes
@slack1596: yes - that generates json that looks the way WP creates it
for plugins weād need something with a little more structure
@will: My preference is to poll but I am not set on that as being a requirement - if someone builds a webhook acceptor we will swap to it. I donāt want how we get the data to be a blocker to moving forward with other parts of building.
@jnylen: We will need a polling process at first anyway, something that takes a list of GitHub repositories and converts them into data about installable plugins
Weāll need to run this several hundred times (or more) during development, so webhooks wonāt really work there
@will: If we are not to be looking at CP for the place to base from which alternatives to look into do people suggest?
I mean maybe I could play the devil and suggest WPā¦!!! Lol
Nah I joke of course 
@jnylen: Yes, Gutenberg blocks would be perfect here
@will: But I do not know what else to look at except CP.
@jnylen: @will if you are amenable to building a prototype in CP, knowing that we may want to extract out the relevant bits later on, then we will be happy to accept the help
@will: Perfect I will prototype in CP and see how it works
@blueskyphoenixllc: Is there some way to create some sort of compromise between what William is proposing and what James/Invisnet want? (this is mostly a rhetorical question, but intended to provoke thought)
@wade: Long term we had spoken about Laravel - if I recall correctly (sorry just getting caught up now)
@will: There can be a balance between the 2
But I cannot build the webhook acceptor as I have not got the skills or experience to do it well enough.
@elisabetta.marina.cle: I have got a little question on this. What we need is something handling not only plugin/themes listing but also updates? Like a plugin to manage updates from external sources in wp?
@jnylen: Yes, donāt worry about the webhook part for now, we need to have something up and running before that becomes a consideration
@wade: I can help with Laravel - I have more experience there then I do with WP/CP
@jnylen: And yes @elisabetta.marina.cle handling version updates will be part of this system
@elisabetta.marina.cle: Ok. So maybe the code handling this in some famous plugins may spark ideas in terms of security? How are those plugins blocking attacks for example? I think updates are served via APIsā¦
@norske: If I catch the idea,
polling is ok in a short perspective until there are hundereds of outdated (dead) plugins
webhooks benefit in a long perspective
@elisabetta.marina.cle: (I have seen plugins to serve upgrades from own repos. Itās basically that we serve them from many repos but the security needed is just the same)
@jnylen: polling (or regenerating everything) is also the only way to build this during development
(during development, weāll need to update the data many times, but we wonāt have so many version updates from plugins)
@elisabetta.marina.cle: If I understand correctly polling means the system checks continuously for changes against repos?
@jnylen: @elisabetta.marina.cle one potential issue with serving upgrades from many repositories is that someone can decide to take their repository down
other than that, I donāt think there is much difference
@elisabetta.marina.cle: Yes, but fact is we want a directory. So we are obliged to let plugins be self hosted by devs in a place like GitHub for example. GitHub is a big collection of repos, so basically is like having to keep every repo in checkā¦
@slack1596: ok, on webhooks: securing the endpoint is trivial for github as they publish a list of their ip addresses: https://api.github.com/meta
@elisabetta.marina.cle: Or we just build our own GitHubā¦
@jnylen: we have discussed doing a full clone of each repository ābehind the scenesā
e.g. nylen/someplugin gets cloned to ClassicPress-plugins/nylen__someplugin, both on GitHub
and we only use our version if needed
this is also something to solve for later, for now we can just start with trusted users
@elisabetta.marina.cle: I am not speaking of cloning the GitHub, but having our own hosting platform for code
@jnylen: see emoji above
@elisabetta.marina.cle: Yeah. I know
@ALS: Doesnāt that defeat the point of a directory? 
@will: Gitlab is a popular code host but itās pretty bulky to manage I hear.
@elisabetta.marina.cle: But letās just keep the idea for a later time
@jnylen: yes, at that point weāve built a full repository
@elisabetta.marina.cle: Yes, butā¦ Question: is a directory suitable to manage the complexity of having millions of themes/plugins like WP has or at some time we are going to need something more?
@slack1891: WP doesnāt have millions 
@elisabetta.marina.cle: I think a directory is much better than a repo, but as of now we are ālittleā and growing. What will happen when we will be all grown ups?
āmillionsā just to say a ābig numberāā¦
@jnylen: itās actually the other way around - much harder to scale a repository, because then you have to pay for hosting
@ALS: Plus, it depends on your business model.
@jnylen: as long as we donāt make any major mistakes then we will be able to scale this approach pretty much indefinitely
@norske: Letās be realistic, building a repository is overengeneeriing for now anyway. It btings more problems thn benefits. And since moving to Github was declared as a feature thereās no need to reinvent this
@elisabetta.marina.cle: Ok. So basically we need a big āupgrade from GitHubā site serving code listings.
@jnylen: install/upgrade from GitHub, yes
@elisabetta.marina.cle: Uhm. I have my hands dirty with some code I am writingā¦ But itās similar to what a digital files listing has to be. And the update/install thing sparkled an idea in my mind.
@will would a structure with custom CPT integrated with a plugin allowing for install/update from GitHub work for that? As a first step structure I meanā¦
The plugin for install/update may check listing against its source to find if there are changes every xxx hours.
And overwrite those plugins/themes that have been changed on their source
@will: Yeah is essentially the idea we have overall here. You learn fast
@elisabetta.marina.cle: Updating at the same time the listing
@will: We have a CPT (or possibly JSON files) that holds info about the plugin. Every so often we check GitHub to make sure our information is current and if not we update our own records.
@elisabetta.marina.cle: Maybe the difficult part is check against the source. But like this I think itās feasible with CP. And in future it may be evolved.
I think @slack1891 plugin for a minidorectory does basically thisā¦
@will: One suggestion offered here was webhooks which can actually mean we donāt need to periodically check source - source tells us when itās updated.
@ALS: Just askingā¦
WordFence has this feature where it compares your files to the core files and highlights any changes.
Wouldnāt it be worth it to check out their method?
It may not necessarily be the best one.
But good to know your options.
@jnylen: @ALS what would this be intended to address?
@elisabetta.marina.cle: I think the webhooks part is out of my skills, but I may help with all things I am able to understand :rolling_on_the_floor_laughing:
I think checking against source @jnylen
@ALS: Well, you said webhooks is for later down the road, right?
So for now, the source wonāt be telling us when it is updated.
So you would need a way of comparing the two versions.
@jnylen: Ah. Thatās basically what is meant by āpollingā, but since we are using GitHub we will ask GitHub instead of having to compare files
@elisabetta.marina.cle: The risk IMHO in polling continuously is that means continuous db queriesā¦
So itās better @jnylen method of ālisteningā to GitHub
@ALS: Thanks, James.
@will: @ALS Wordfence compare of files is CPU intensive and slow. GitHub does the CPU intensive stuff and creates a hash for us to use. Comparing if that number changes is sufficient to know if any part of the entire software has changed bonus is we can use it for added security down the line
@elisabetta.marina.cle: So we will require as a minimum they host plugins in GitHub with semver.
@jnylen: Not necessarily semver required for every plugin, though that is the ideal
GitHub with tagged version numbers, and we can also look at supporting Gitlab etc when the initial version is off the ground
@elisabetta.marina.cle: I think educating them to semver by encouraging it is a good goalā¦
@ALS: So, can this be done as a batch process?
@jnylen: People with existing WP plugins should be able to list on our directory too
@ALS: Letās say, check the version number once a day?
@elisabetta.marina.cle: Uhm. I see the point in not making it a requirementā¦
@ALS: Checking significantly more than once a day seems unnecessary to me?
@will: When eventually we move to webhooks it will be easy to support any platform and any version choice probably. Early in the process it may be limited to just GitHub and only tagged releases.
@elisabetta.marina.cle: Ok. So first thing first. Make the cpt code work perfectly to serve digital files
@jnylen: Another thing we need is the ability to release zip files along with a tagged version, for when the release doesnāt match the source tree exactly. GitHub and Gitlab (I think) support this.
@elisabetta.marina.cle: That is the easy part, because then it will need the install/update partā¦
@jnylen: We will also want to rely on the underlying guarantees of git in many ways, so weāll probably always limit to git repositories
@ALS: Can we discuss at some point what the process will be for becoming a ātrustedā contributor?
Doesnāt have to be now.
But that sort of thing should be prominent in the documents.
@elisabetta.marina.cle: I am interested in that too
@jnylen: Trusted in what sense specifically?
@will: +1 about needing to get the proper release zip. More often than not what you clone from master or develop branch is not ready to install as is.
@ALS: I read somewhere earlier in this conversation that the initial version will probably need to be restricted to trusted contributors.
@norske: Is there any real need in ātrustedā/āuntrustedā statuses at all?
@ALS: I can find it later once the conversation is more quiet. Can shelve it for now.
@jnylen: Ah, I mean that we wonāt be ready to open up plugin submissions to everyone just yet
@ALS: Exactly.
@wade: I think what James means is that we have two tests cases to build on
but once we are production ready it will be open for submissions
@ALS: But there are other plugin authors tagging ClassicPress in the directory with 20k+ installs that I canāt find on the forum or on Slack.
@elisabetta.marina.cle: Oh, I think it was referred to those people that are developing ācustom solutionsā for CP like @slack1891 plugins, or @laurence
@jnylen: Yes, ātrustedā was an ambiguous word here, I meant the plugin authors who we already know are active in our community
@elisabetta.marina.cle: We will use them to test the system.
@ALS: I agree with that.
@elisabetta.marina.cle: But this means that for some time there will be an āhybridā system?
@ALS: But there may be new people coming in with established reputations. And they may like to volunteer.
So āWho do I contact to volunteer?ā would be something I would include in a FAQ.
@elisabetta.marina.cle: Yes @ALS. But no point in allowing them in a not tested environment with flaws and bugs.
@ALS: Or something to that effect. Not necessarily exactly that.
@elisabetta.marina.cle: I thinkā¦ There are two levels.
@jnylen: We already have most of that information but it is spread across our existing site and documentation
@elisabetta.marina.cle: Contributor is someone who contribute code to CP core. And a plugin dev is someone who may be listed in directory. However I think itās too soon to show people the way to the directory. And for core contributors there are CTAs in place
@ALS: I would argue that āunbiasedā eyes becomes important as soon as you start with user experience.
@elisabetta.marina.cle: I mean, even if we roll out the directory, I think it needs testing for some time prior to opening.
@norske: @ALS there is a list of team leads on a page āGet involvedā on classicpress.net. Maybe this is a general solution for entrance?
@elisabetta.marina.cle: We do have testers for alpha and beta testings (those known devs referred before)
And before speaking of user experience we have to be sure it works and itās secure.
@ALS: Not arguing with that, Elisabetta.
But we can deal with the nuance on another occasion in a different forum?
@jnylen: (At this point we have moved into āopen floorā, folks are welcome to continue chatting but Iām not going to be able to run the meeting any more)
So thanks everyone for attending and participating
@will: Thanks @jnylen for running the meeting. We have kept you here for nearly 2.5 hours! Lol I am still around to chat if anybody want to though
@ALS: Iām going to be trying out my new ClassicPress install.
@elisabetta.marina.cle: Going to eat dinner and think about everythingā¦ Thanks @jnylen and everybody involved
@jnylen: @will I am curious what you see as the main differences between a plugin directory and a theme directory - I am more familiar with plugins, along with most people here I think
@will: On a technical level I donāt see there is much difference. Especially not with a directory (as opposed to a repository).
Both have an ID of some kind, a version string, the source location and a description (plus sine assorted other user data).
@jnylen: I think the presentation would need to be different, but other than that I wasnāt aware of much that would need to change either
@will: We can probably use 95% of the same backend code for both. Frontend display is where most differences would be seen.
@ALS: As a user, I would prefer a very similar look and feelā¦
@will: I expect some design or UX person could highlight what presentation difference would be suitable but for a real simple case just show a description and a button linked to source could be the basic starter template for both sides.
@ALS: Has anyone here checked out CPās mini directory?
The other CP :rolling_on_the_floor_laughing:
@blueskyphoenixllc: There are a number of ways to present the data that creates a similar look & feel but differentiates between the two. Happy to have a further discussion on that ā
@ALS: Iām asking because I really like the way that the information tabs are structured.
And he explicitly had it on his site that it isnāt intended to compete with or replace the directory, it is a temp measure till it goes up.
Itās a really good user experience.
@blueskyphoenixllc: I havenāt seen it yet
@norske: themes presentation is based on filters describing its layout and functionlity. itās probably the most specific difference, as plugins are less multioptional
@ALS: You can just ask for a username and password via DM, Michelle.
@jnylen: This is Code Potentās list of his plugins? Is the link not public yet?
@ALS: He sent it to me because he asked for help with testing and I asked for the link.
Let me check if it is public.
@jnylen: Ah, yes, not yet
@ALS: The link I have still requires authorization.
He may have published the final version on a different URL.
@norske: @blueskyphoenixllc, is it acceptable to offer some changes/extensions in design guidelines? Or they are strict and unchangeable?
@blueskyphoenixllc: Theyāre in flux right now; weāre in the middle of a site redesign and Iāve stripped down the design guidelines quite a bit from the originals. That said ā yes, happy to have a conversation about it over in design if you want to chat there
@slack1891: @ALS is right, the Plugin Directory (plugin) was just publicized for a short time to allow others to poke at it and see if anything broke or looked wonkyā¦a light user testing session. The demo is no longer, but, it will be onsite soon.
@ALS: 
@slack1891: ā¦looks like Iāve got some catching up to do
@will: Is there a formal process in place where meeting notes are written and shared on the blog in some way?
@blueskyphoenixllc: Iāll tag @wade on this ā
@will: The meeting was long today so I dint know if anyone was able to hang around the entire time, except maybe James. But I would hate to put anything else on his plate as I see he is incredibly busy already keeping us lot wrangled in lol
@blueskyphoenixllc: In short, there is a process by which the conversation is ported to the forum. Iām glad you mentioned it because thereās a lot that was discussed here and weāll want to save it before it gets 10kāed by Slack.
@will: Thatās a lot easier than note taking