| diana_coman: | http://ossasepia.com/2020/04/21/ossasepia-logs-for-08-Apr-2020#1023954 - perhaps/possibly some custom php functions otherwise but that's about it indeed; (my theme is exactly that, the css + a custom function). | [04:49] |
| ossabot: | Logged on 2020-04-08 20:27:37 trinque: I'm pretty skeptical that there's any need for theming other than custom css. | [04:49] |
| diana_coman: | http://ossasepia.com/2020/04/21/ossasepia-logs-for-08-Apr-2020#1023938 - heh, files are just db-on-disk and "config data" is still...data. | [04:50] |
| ossabot: | Logged on 2020-04-08 18:20:51 jfw: personally I'd prefer more config through... config files, and leave the database for... data! hence my suggesting a wp-config.php variable. it'd be a question of whether one cares about admin GUIs. | [04:50] |
| diana_coman: | the trouble with having the flags/options/configs/whatevers on disk instead of in db is that you have to further back those up separately. | [04:52] |
| billymg: | hi diana_coman | [14:56] |
| billymg: | hmm, i see your point re: config file vs. db, though i don't thinking having to backup one config file, wp-config.php, is too much to ask (especially since users are likely backing this up already as it contains the db config) | [14:59] |
| billymg: | s/thinking/think | [15:00] |
| billymg: | and the advantage of consolidating config into wp-config.php is that you no longer need the gui and mysql code to support updating the config data in the db | [15:03] |
| billymg: | though to be fair this is not a lot of code, just a few html inputs and sql queries | [15:04] |
| trinque: | billymg: but don't you have to justify to yourself two places to express the same thing? | [15:11] |
| trinque: | even if pratically you don't take it on right now, which I'd understand | [15:12] |
| trinque: | everything in the V tree of life ought to be grinding towards "there is one truth" or otherwise it frays out into meaningless hell | [15:13] |
| billymg: | http://ossasepia.com/2020/04/22/ossasepia-logs-for-09-Apr-2020#1023972 << so if there is to be one place instead of two then to me it seems wp-config.php would be that place, since it contains the db config itself and therefore can't be moved into the db | [15:26] |
| ossabot: | Logged on 2020-04-09 15:11:48 trinque: billymg: but don't you have to justify to yourself two places to express the same thing? | [15:26] |
| diana_coman: | billymg: it's not at all (nor can it ever be) about whether it's "too much to ask" or not, ugh. | [15:32] |
| diana_coman: | for one thing that sort of "justification" is a slippery slope (when and what exactly and by whom is to be deemed "too much"?) | [15:32] |
| diana_coman: | and for another thing, even more importantly, the question is whether it's the correct thing to do, not whether someone finds it too much or too little; the point re backups was not because of the difficulty of backing up files on disk too, lol | [15:34] |
| diana_coman: | pretty much as trinque says, the question there is what justifies 2 places instead of 1 for the same thing. | [15:35] |
| diana_coman: | billymg: also, I don't get what has the UI to do with this? mysql sure, but that is needed for as long as the database is in use so hardly anything added. | [15:36] |
| billymg: | diana_coman: ok, i understand your and trinque's point about it being about which is the right thing, and not about saving some time, or some code, or being "too inconvenient" or whatever else | [15:37] |
| billymg: | diana_coman: the UI for the inputs that fire off the queries to update the configs in the db, which i admit is about "convenience" since one can always open mysql and execute the queries themselves | [15:40] |
| diana_coman: | billymg: I wasn't even quite aware that existed really since I always use mysql, yes | [15:40] |
| diana_coman: | billymg: who wants to have that can add it to their own installation presumably, not an issue as such | [15:41] |
| diana_coman: | and/or even maintain a branch with it, sure | [15:41] |
| billymg: | http://ossasepia.com/2020/04/22/ossasepia-logs-for-09-Apr-2020#1023984 << aha, this i was not aware of | [15:43] |
| ossabot: | Logged on 2020-04-09 15:40:37 diana_coman: billymg: I wasn't even quite aware that existed really since I always use mysql, yes | [15:43] |
| billymg: | diana_coman: is your workflow the same for any mp-wp config (i.e. everything in the wp-admin UI under "Settings" in the left-hand nav)? | [15:43] |
| diana_coman: | billymg: that q doesn't quite parse for me - what do you mean? | [15:45] |
| billymg: | i mean, let's say you go to update your date format, or tagline, or comment moderation rules.. do you open mysql and edit the db directly, or check the boxes in the wp-admin UI and click "save changes"? | [15:47] |
| diana_coman: | billymg: hm, you know I ~never needed to update those? lolz; I tend to do it at install time via mysql and then let it be | [15:47] |
| billymg: | diana_coman: sure, so they're rarely ever altered, but it sounds like when you do set them, it's via mysql and not the UI | [15:48] |
| diana_coman: | that's a bit part of the issue there really - most of those are not all that useful knobs to start with, they are in fact circumventing-having-to-know knobs, pretty much | [15:49] |
| diana_coman: | billymg: indeed. | [15:49] |
| billymg: | http://ossasepia.com/2020/04/22/ossasepia-logs-for-09-Apr-2020#1023985 << this is where i think i'm struggling at the moment. initially this was my thought as well, but jfw made the point that as maintainer of the "base" branch (or whatever) i should aim to minimize friction for others following the branch | [15:51] |
| ossabot: | Logged on 2020-04-09 15:41:14 diana_coman: billymg: who wants to have that can add it to their own installation presumably, not an issue as such | [15:51] |
| diana_coman: | billymg: but again, one person's workflow is not really the way to decide on what's the right thing to have. | [15:51] |
| diana_coman: | I suppose I'll call those obscurantist-knobs, lol | [15:51] |
| diana_coman: | billymg: he has a point but I doubt that has to do with "add any functionality someone wants", hm | [15:52] |
| diana_coman: | because that anyway doesn't scale | [15:52] |
| billymg: | > they are in fact circumventing-having-to-know knobs << i'm not sure i understand this description, what does the user avoid having to know by having these knobs? | [15:53] |
| diana_coman: | billymg: mysql and the db structure | [15:53] |
| billymg: | diana_coman: ah, i see, in as far as those knobs are part of the db structure in the first place (and not hardcoded to a sane default, for example) | [15:55] |
| billymg: | http://ossasepia.com/2020/04/22/ossasepia-logs-for-09-Apr-2020#1024001 << right, so i feel i'm back to wearing my product designer hat and asking "what gets included as standard, what is included as an option, and what is excluded?" | [15:58] |
| ossabot: | Logged on 2020-04-09 15:52:33 diana_coman: because that anyway doesn't scale | [15:58] |
| diana_coman: | billymg: the way I see "minimise friction", it means a. talk to people using/maintaining it - but this means literally keep them in the loop and weighing in, don't surprise them mainly b. provide the sanest set of default working structure basically | [16:02] |
| diana_coman: | perhaps add c. aim to isolate the core so that maintaining a branch doesn't involve a lot of intricate regrinds, merely a move this on top of that or the other manifest file | [16:03] |
| diana_coman: | ie make regrinds as painless as they can be, perhaps. | [16:03] |
| billymg: | diana_coman: a. was my conclusion as well http://ossasepia.com/2020/04/22/ossasepia-logs-for-09-Apr-2020#1024001 | [16:04] |
| ossabot: | Logged on 2020-04-09 15:52:33 diana_coman: because that anyway doesn't scale | [16:04] |
| billymg: | diana_coman: c. i like a lot in theory lol | [16:04] |
| diana_coman: | well, it's ~all theory so far since not much experience with V-maintainers as such, anyway | [16:04] |
| diana_coman: | anyways, jfw, do you care to go into more detail on what you see as approach to minimise friction with maintainers? | [16:06] |
| billymg: | diana_coman: so what i used to do in saltmines when faced with a problem like this was put together a "user research" plan. it might consist of user interviews, a survey/questionnaire, shadowing (i.e. watching the operator perform normal tasks with the software) | [16:07] |
| billymg: | diana_coman: i think it might be useful if i put together a list of questions (not many, likely less than ten) for mp-wp users so that i can gain a better understanding of how everyone uses it | [16:08] |
| diana_coman: | billymg: yeah, I know the full set of user interface design tools and approaches and everything (did several reviews of that area at various times too, fwiw) | [16:08] |
| billymg: | diana_coman: ah, cool! | [16:09] |
| diana_coman: | billymg: yeah, except mhm, are you aiming to minimise friction with people's existing habits ? ie if someone says they use it on Windows, you'll support that ? | [16:09] |
| billymg: | yeah, because currently i only know well how *i* use it, and only bits and pieces of how others use it | [16:10] |
| billymg: | diana_coman: if 9/10 users here used windows then yeah (or at that point just give up on the project lol) | [16:11] |
| diana_coman: | billymg: that doesn't sound very sane to me really. | [16:11] |
| billymg: | perhaps not solely the \% of users, but who those users are then? | [16:11] |
| diana_coman: | ie you are saying there that you are stuck supporting bad habits just because they are spread widely enough, right? | [16:12] |
| billymg: | diana_coman: hrm, good point. i defaulted to putting myself in the helpless position | [16:12] |
| diana_coman: | to my mind the more important part is understanding (possibly better than users, yes!) what the software is meant to solve (and what NOT, ie scope!) and what's the most effective way to do *that and nothing else* | [16:13] |
| diana_coman: | ie make the trunk of mpwp so that I'm 2x more productive using it than whatever entrenched habits I might have, and I'll change the darned habits already | [16:14] |
| billymg: | diana_coman: no argument there, that's certainly the highest goal a designer can aim to achieve | [16:15] |
| diana_coman: | billymg: btw, all those shadowing and watching users and so on, I always took to be more about figuring out the actual *requirements* ie what the users are trying to achieve, not what habits they have | [16:15] |
| billymg: | diana_coman: yes, exactly | [16:15] |
| billymg: | diana_coman: you see that all these disparate users have cobbled together the same set of scripts to solve X because your product doesn't and you then build it in for them | [16:16] |
| diana_coman: | (that being said, I still feel a bit sick with all the recollection of that area, lol) | [16:17] |
| billymg: | haha, apologies, it was my life for a long period of time (i do believe the fundamentals useful though, as we're discussing now) | [16:17] |
| diana_coman: | billymg: heh, no worries; my trouble with it is more that it's very limited and overall unclear if it's worth it really (ie you can get what they already do, but not what nobody even thought of yet, pretty much) | [16:19] |
| diana_coman: | and iirc some could get very bureaucratic and detailed and all that, ugh | [16:20] |
| billymg: | diana_coman: aha | [16:20] |
| diana_coman: | I see its point esp when no domain knowledge otherwise, sure; but kind of ...insufficient I'd say; better than nothing but not going too far just by itself, that's all. | [16:20] |
| billymg: | diana_coman: yeah, the "what nobody has thought of yet" never came from "process" but rather from tuned in individual who internally synthesized enough of the research output | [16:21] |
| billymg: | and was then able to describe and promote (re: "sell") their vision | [16:22] |
| diana_coman: | that's pretty much part of "own it", too, the way I see it. | [16:22] |
| billymg: | diana_coman: indeed, yes, that makes sense | [16:24] |
| diana_coman: | and you know, if you spend time on it anyway, I'd say it's the only way in which that time spent is justified, too; not an empty "did lots of work on it", nor "bent to each and every user's whims and habits" but a very obvious "got to understand the *problem* way better than anyone else and therefore I have now better *solutions* than anyone else, too" | [16:25] |
| diana_coman: | that being said, feel free to ask anything re use of mpwp, sure, I don't mind any questions on that, why would I mind them anyway | [16:25] |
| jfw: | Got an article in the works here, I thought it was going to be a quick thing showing some code and results but turns out to be 800 words and counting. | [16:27] |
| diana_coman: | jfw: heh, not-bad; I was just noticing in fact that your plan didn't mention any articles/writing as such, glad to hear it's just so-usual-it's-not-even-mentioned-in-the-plan-anymore ! | [16:28] |
| jfw: | just gotta make the not-writing less usual is all! | [16:29] |
| diana_coman: | ahaha, maybe set it strictly in the plan, if it helps? "plan sez must-not-write-today therefore WILL WRITE" ? | [16:30] |
| jfw: | nearly snorts coffee | [16:30] |
| diana_coman: | plans and antiplans, what; (who said it all needs to be that serious anyway) | [16:32] |
| billymg: | http://ossasepia.com/2020/04/22/ossasepia-logs-for-09-Apr-2020#1024043 << sounds good, i'll put something together then | [16:45] |
| ossabot: | Logged on 2020-04-09 16:25:44 diana_coman: that being said, feel free to ask anything re use of mpwp, sure, I don't mind any questions on that, why would I mind them anyway | [16:45] |
| dorion: | http://ossasepia.com/2020/04/21/ossasepia-logs-for-04-Apr-2020#1023640 - it's okay, thanks. for now, better than panama city. their curfew/quarantine is one of the strictest : men are restricted to 2 hrs/day based on cedula number monday, wednesday and friday and women same tuesday, thursday, saturday - everyone off the streets sunday ! | [17:03] |
| ossabot: | Logged on 2020-04-04 15:12:42 whaack: dorion and jfw: How is it going bunkered up with the family? It is sad to say that had the recent shennanagins not been going on, we would likely be meeting for a drink today. I hope you two are able to make it back shortly, and when you do you should pay a visit to billymg and me. We've had success mixing different fruit with rum. | [17:03] |
| diana_coman: | ahahaha, that's communist traffic style (cars with odd number licence plates can travel on some days, those with even numbers on different days). | [17:07] |
| diana_coman: | but seriously, that sort of thing is not out of nowhere ie it's not like they are sane otherwise, only now discovered such bright ideas. | [17:08] |
| jfw: | after all, no one car matters more than any other. | [17:08] |
| whaack: | CR is doing the only certain plates on certain day thing atm | [17:13] |
| jfw: | http://ossasepia.com/2020/04/22/ossasepia-logs-for-09-Apr-2020#1024014 - context was what do users of V software do if they want to make small tweaks to their own copies?. For things that necessarily vary between installations, such as theming (and content too! seems obvious that belongs in the database, but one | [17:25] |
| ossabot: | Logged on 2020-04-09 16:06:50 diana_coman: anyways, jfw, do you care to go into more detail on what you see as approach to minimise friction with maintainers? | [17:25] |
| jfw: | could imagine doing it in V), making the tweaks possible without having to branch the v-tree is a way to reduce friction of following a maintainer's branch. If on the other hand it's a thing that doesn't justify the cost of optionality, maybe one shouldn't be doing those local tweaks to begin with. | [17:25] |
| jfw: | http://ossasepia.com/2020/04/22/ossasepia-logs-for-09-Apr-2020#1023964 - this is true of course, "it's all just a bunch of ones and zeros anyway!" but I argue there is a meaningful distinction, similar to "code vs. data" even though code is a kind of data, and whether or not correctly realized as filesystem vs sql. Perhaps better put as presentation vs. content. | [17:40] |
| ossabot: | Logged on 2020-04-09 04:50:30 diana_coman: http://ossasepia.com/2020/04/21/ossasepia-logs-for-08-Apr-2020#1023938 - heh, files are just db-on-disk and "config data" is still...data. | [17:40] |
| jfw: | http://ossasepia.com/2020/04/22/ossasepia-logs-for-09-Apr-2020#1023966 - does this generalize to apache/mysql/php configs and logs? | [17:45] |
| ossabot: | Logged on 2020-04-09 04:52:30 diana_coman: the trouble with having the flags/options/configs/whatevers on disk instead of in db is that you have to further back those up separately. | [17:45] |
| trinque: | jfw: heh, you might be amused at how far I took that question once upon a time. | [17:56] |
| trinque: | I worked for a guy once that very much did believe everything was better off living in the database, including all that. | [17:57] |
| trinque: | pragmatism might want to drag consistency in the other direction though, towards files | [17:57] |
| trinque: | back on the lulz for a sec, this did yes involve both postgresql and FUSE | [17:58] |
| trinque: | total madness. | [17:58] |
| jfw: | lol! imagining now the bootloader since ofc the postgres binary needs to live there too | [18:31] |
| feedbot: | http://trilema.com/2020/the-kids-know-words-or-the-post-lulz-festival-of-pointless-imbecility/ << Trilema -- The kids know words, or The post-lulz festival of pointless imbecility | [19:57] |
Comments feed: RSS 2.0