Dev meeting 2016 08 30

Agenda

• Bus factor: What needs documenting, distributing, to keep core + assets + dependencies (e.g. news.bolt.cm) running
• 3.2 blockers — https://github.com/bolt/bolt/issues/5686
• 3.2 triage — @SahAssar et al
• Process communication failing — Contributors reporting a feeling of being "blocked"

Actionable Items

Outcomes

Log

<gawainlynch> ping Bopp carsonfull gawainlynch phillipp rarila rixbeck rossriley SahAssar
<rarila> peng
<gawainlynch> Evening, rarila 
<SahAssar> Here!
<rarila> gawainlynch: eveningtoo
<rarila> … there and everythere
* gawainlynch is back to beer-free Tuesday's :-/
<rarila> wahhh
<carsonfull> here
<SahAssar> rarila: You want the be the de_DE guy at https://github.com/bolt/bolt/wiki/Translation-maintainers ?
<SahAssar> Otherwise phillipp is willing to take it :)
<Bopp> pong, sorry.. IRC crashed
<gawainlynch> SahAssar: While waiting for Bopp, do you think you could schedule a triage pass on issues for 3.2 soon
<gawainlynch> Zero stress, Bopp :-)
<rarila> SahAssar: if there's someone else I'll save my time for js_JS then :)
<SahAssar> rarila: Sounds good :)
<gawainlynch> OK… so last week our *.bolt.cm certificate expired (26th) and it was a fun couple of days to migrate most of the rest of our assets over to the new server and ACME (LetsEncrypt) keys
<[BoltGitHubBot]> [bolt] bobdenotter opened issue #5720: "Index.twig is not defined" or ".htaccess doesn't exist" when `.bolt.yml` is missing.. https://git.io/viJ0a
<SahAssar> gawainlynch: Yeah, with our joomla issues sorta sorted I'll get on that this week
<rarila> SahAssar: that's somezthing non coders that want to help can do – add me if you find noone else
<rossriley> Late checking in
<gawainlynch> One problem left is that we're out of key requests to complete news.bolt.cm and cheatsheet.bolt.cm 
<rarila> God save the queen!
<gawainlynch> Evening rossriley … just updating on the certificate problem
<gawainlynch> It raised a problem, that we had bus factor on Bopp for the cert and a lack of planning around it
<gawainlynch> So as we've been pumping out more docs recently, we've created a store that we're going to document more of this, and initially SahAssar and I will do rotation on server maintenance
<Bopp> yeah, and a stupid coincidence that it happened when i wasn't there. 
<gawainlynch> Bopp: Yeah, it happens … zero stress :-)
<gawainlynch> Can anyone think of other points that need attention in the same way?
<SahAssar> And it highlights some issues we might not have thought about otherwise :)
<gawainlynch> Yes
<Bopp> one other thing, perhaps: writing news postings and such for releases. 
<SahAssar> Not really... I have one with extension translations, but that's probably better in an issue
<gawainlynch> Also, related to internal process … we had a community member reach out to Bopp & I today, and one thing they we're under the impression of was that certain areas are "untouchable" and owned by a core dev
<Bopp> i've documented the release process, but it might be good to have a fallback for writing these postings too. Not that i mind doing them, but bus factor and all.
<gawainlynch> Bopp: 3.2 blockers
* gawainlynch hands over the mic
<SahAssar> gawainlynch: Anything in specific, or was it a general impression?
<Bopp> about the blockers.. 
<Bopp> imho, we keep to the projected freeze date, 
<Bopp> land what we can in the meantime
<Bopp> and everything that falls outside of that gets pushed to 3.3...
<Bopp> Let's keep up the pace of "smaller, incremental" releases. 
<gawainlynch> SahAssar: Yes, specific but doesn't gain value from isolating core team member or code, much to say as the understood that is the way things are "as I am a developer too" … the thing we need to try and change out there is the impression that is the case, instead of being there to mentor
<Bopp> If gawain's error handling and hopefully ross's work lands, i think that's plenty to warrant a 3.2 release.
<gawainlynch> Bopp: +1
<SahAssar> gawainlynch: Right, gotcha
<gawainlynch> FWIW the error handling is in … there is just the tidy up phase now
<Bopp> SahAssar: On the one had we need PR's that are _good_, but at the same time, we shouldn't scare people away by making it too hard for people to join. 
<Bopp> euh yes, can't form sentences here. :-)
<gawainlynch> Bopp: You've been hanging out too close to me then ;-)
<Bopp> i've had this skill for ages! 
<gawainlynch> OK … so does anyone else have anything to raise?
<SahAssar> agreed, I was mainly asking since I'm guessing we have areas that are more open and areas that are less open. Which are which might not be fully visible from inside the project.
<gawainlynch> SahAssar: Yeah, more docs needed … absolutely 
<gawainlynch> SahAssar: All yours then
<SahAssar> </meeting>
<Bopp> .. and somehow some way to actively engage wannabe-contributors.
<gawainlynch> #beer
* [BoltIssueBall] $this->app['bartender']->setDrink('beer')->setTab('gawainlynch')->serveAll();
<Bopp> duuuude. ;-)
<gawainlynch> Not really … I'm living vicariously though the bot
<Bopp> i was actually referring to SahAssar, closing the meeting while i was typing a sort-of-relevant response
<SahAssar> PhillippOhlandt and gawainlynch have been added to https://github.com/bolt/bolt/wiki/Translation-maintainers btw ;)
<gawainlynch> Oh… sorry … that is actually my fault, Bopp 
<SahAssar> Bopp: sorry mate, I'll reopen :)
<SahAssar> <meeting>
<Bopp> haha
<Bopp> .. and somehow some way to actively engage wannabe-contributors.
<Bopp> there! :-)
<SahAssar> Yeah, I'm not sure how we do that though... Any bright ideas?
<SahAssar> besides being generally firendly?
<Bopp> not yet.. 
<Bopp> except for being approachable, but that's part of what you mentioned. 
<gawainlynch> Being clearer about our process, in very simple and accessible form
<Bopp> still, it's something to think about 
<rarila> SahAssar: btw, you could link to the github account
<SahAssar> Hmmm...
<gawainlynch> SahAssar: About those translations roles
<gawainlynch> I think someone should be in charge of en_GB
<SahAssar> Our general process is very open (99% of our communication is in public) but it's not easy to see "the forest for the trees" I think. is that the issue you are talking about?
<gawainlynch> We have non-native speaker contributing, and they shouldn't have to feel that their English strings have to be grammatically, or otherwise, at a high level 
<gawainlynch> SahAssar: Yeah, collectively (forest vs tree)
<gawainlynch> I don't specifically know what we're doing wrong, just want to raise it and get a conversation happening :-)
<Bopp> I don't think we're _wrong_ per se.. Just that there might be room for improvement.. If only in how people perceive it.
<SahAssar> gawainlynch: If someone needs help with a en_GB string they should feel free to get help on it, but any PR that changes a base translation or adds one should be in the PR that adds/changes it.
<SahAssar> IMO.
<Bopp> I mean, i know we are all willing to help, so that's not the issue. 
<gawainlynch> SahAssar: Never that easy :-)
<gawainlynch> …and we should be aiming for key base strings only 
<Bopp> we need to make sure people aren't hesitant to contribute. 
<gawainlynch> Bopp: Yeah, where I was heading in my mind too
<SahAssar> Okay, we're overlapping here, so I'll postpone the translation stuff :)
<gawainlynch> +1
<SahAssar> My question is if we have anything actionable to help this out? Better core dev docs? Anything else?
<SahAssar> (at this point, I get that we'll get better as we go)
<gawainlynch> Actionable, yes 
<gawainlynch> Keep an eye out for how people are interacting with a problem/bug they are trying to solve in core, and see if there is scope to encourage and offer support to get a PR in 
<Bopp> yes, sounds good.
<gawainlynch> Telling people "PR welcome" is true, but if they are afraid of what response that PR might get
<gawainlynch> Everyone is heavily time limited, so IMHO in the long run we start to turn up people who continue to contribute and grow with the team and community 
<SahAssar> "PR welcome" is also a phrase that has some... odd connotations for some people
<gawainlynch> Possibly 
<gawainlynch> So are we all good for this one?
<gawainlynch> </addendum></meeting>{{ <?php echo "\n"; }}
>ChanServ< op #boltcms gawainlynch 
<Bopp> years ago, you'd often see: "It's open source. You don't get support, because you can fix it yourself" 
<Bopp> which is a terribly stupid thing to expect of common users. 
<SahAssar> And now that is often shortened to "PR welcome"
<Bopp> perhaps "PR welcomed" 
<Bopp> yes, that. 
<SahAssar> The hard part is to balance between being "excessively controlling" and "Fuckit, fix it yourself"
<Bopp> Yes, it's food for thought, though 
<SahAssar> And each person will interpret those differently.
<SahAssar> Anyway, I'll be on lookout for it
<SahAssar> gawainlynch: The idea behind the en_GB translation thing is that we need one source language, that is complete and the "canonical" language, I don't expect us to accept PR's that contain incomplete or wrong translations in that source language... Therefore having a maintainer on it seems redundant.
<gawainlynch> So your point is that the maintainer is just "core"
<SahAssar> My point is that the maintainer is core and the community.
<SahAssar> Any PR adding a translation key but not having it in en_GB I'd expect to be asked to add it.
<gawainlynch> OK, so if there are maintenance issues with the strings, that's just handled as it is now
<SahAssar> you mean with the keys? or with the values?
<gawainlynch> Sorry… values … as in "You ain't wanna prezz dat' buttun" is going to want to be fixed, probably several times :-D 
* SahAssar is outraged. That's not even proper ebonics!
<SahAssar> basically, handling of new keys is expected to be in the PR that adds the key. Handling of fixing existing ones is a little trickier, but I'd expect that to be a community effort.
<gawainlynch> Yeah, they'll probably get spotted pretty quickly
<SahAssar> Although the en_GB messages only have 9 contributors, and the nl_NL has 11. So perhaps nl_NL should be the source language :D
<gawainlynch> I am really thinking that I miss stuff all the time, and edit professionally part of the year … so stuff happens is all :-)
<SahAssar> Who would you think would be good for maintaining en_GB then? Cause currently it's based on active, knows the language and is willing, but that is quite a few for en_GB.
<gawainlynch> rossriley: If you're in the house, I forgot … did you want to push your 3.2 work to 3.3?
<gawainlynch> SahAssar: Not sure … was thinking it would be a good (quiet) spot for someone that wanted to contribute to something with a low barrier to entry 
<SahAssar> gawainlynch: Well, hopefully it won't be so quiet (for at least a little while) if we get the keyword stuff done..
<SahAssar> Also stuff like #4161
-[BoltIssueBall]/#boltcms- #4161 [open] Default 'pages' content type name change has no effect on backend UI https://github.com/bolt/bolt/issues/4161 
* dantleech_ has quit (Ping timeout: 244 seconds)
<gawainlynch> SahAssar: Bopp isn't around … but ContentType translations require the overhaul of Translations
<gawainlynch> Problem is how/when pluralisation is done in some languages
<gawainlynch> …and the ability to provide said translations
<SahAssar> :fire: ContentType translations :fire:
<gawainlynch> Well, that is what Bopp wants, rarila has a differing side
<gawainlynch> I struggle with English … I am almost certainly going to be the one to tackle the PHP code, and that side of the architecture, but that is a discussion for those that actually implement … like yourself
<SahAssar> yeah... I've starting writing up a proposal for it so many times... I hate how we handle it now
<rarila> don't get me on it
* gawainlynch gets rarila on it :-P
<SahAssar> "struggle with english"?
<gawainlynch> SahAssar: Using words ironically 
<rarila> gawainlynch: all said
<SahAssar> gawainlynch: Righ... I should be able to get that now that I've actually met you :D
<gawainlynch> Yeah, and it is also a not-so-subtle admission, or acknowledgement, of my own failings at various times … typing … speaking … eating … coding :-D
<SahAssar> Anyway, translating strings in config files that are expected to be edited by the user makes no sense.
* SahAssar knows that this has been debated over and over...
<rarila> … and over and over …
<SahAssar> But if we don't expect a user to edit contenttypes.yml why the hell is showcases in there?
<rarila> SahAssar: define user
<gawainlynch> Step back … what is a user in this/these contexts
<rarila> gawainlynch: ha! :-)
<gawainlynch> rarila: My thought too :-)
<rarila> brothers in ocd
<gawainlynch> #karma rarila 
<[BoltIssueBall]> Sorry but karma can only be added for channel members, rarila isn't here and they lose out!
<gawainlynch> #karma rarila 
<SahAssar> Right, by user in this case I mean the person setting up the site. If they edit the contenttypes.yml they can probably translate the strings. If they don't we shouldn't have showcases in there.
<[BoltIssueBall]> BoltKarma for rarila is now 156
<gawainlynch> Oh … I see where you are coming from now
<SahAssar> My point is that it's a contradiction.
<Bopp> I am around-ish. Just packing my bag to go to Vlieland tomorrow 
<gawainlynch> :-)
<rarila> SahAssar: then pages shouldn't be there, too. For me all are just sample types. Some ppl seem to see them as the types to use
<gawainlynch> SahAssar: Yes, but that is the thing… the base ones are just to match the base CTs
* gawainlynch is in the middle on this one btw
<SahAssar> rarila: pages and entries generally match pretty well to a standard site structure. showcases do not.
<gawainlynch> Looking at it architecturally, wouldn't these be best added to the users config directory on install, so they can remove showcases in CT & translations
<SahAssar> gawainlynch: But they are also tracked by git, so if anyone edits the CT translations they won't be able to upgrade-
<rarila> SahAssar: still they are just samples that by chance are more useful
<gawainlynch> Yes, but this is also going bck to the point about the work done on our translation service 
<rarila> gawainlynch: that one anyway
<gawainlynch> rarila: Yeah … there's a bit to it
<SahAssar> rarila: I think #4161 disproves that they are just "samples"
-[BoltIssueBall]/#boltcms- #4161 [open] Default 'pages' content type name change has no effect on backend UI https://github.com/bolt/bolt/issues/4161 
* gawainlynch is stepping back, for the moment, on 4161
<rarila> SahAssar: that we just do it wrong at the moment doesn't mean the principle is wrong - It was always on my list to move those ct translations to the config dir
<gawainlynch> ^ which is what I am saying also
<gawainlynch> …and we are almost there. The base install type change was part of this
<gawainlynch> app/ should be the project, not Bolt's directory
<rarila> also theme translations have to be removed from bolt translations
<gawainlynch> ^
<rarila> no need to load backend translations in fronmtend
<SahAssar> For a beginner user (one not versed in translation files in app/config) wouldn't it still have the same effect? Or am I misunderstanding?
<gawainlynch> ^
<rarila> SahAssar: what effect?
<gawainlynch> SahAssar: We need to address loading, how, where, what, how is what available/configured, then we need to validate it, then cache it, then we start
<SahAssar> rarila: That changing the pages name has no effect, as in the original comment in #4161
-[BoltIssueBall]/#boltcms- #4161 [open] Default 'pages' content type name change has no effect on backend UI https://github.com/bolt/bolt/issues/4161 
<rarila> SahAssar: that's another scenario and there are two positions where mine is, no localisation (that means just text for only one language) should be in the data definition file
<rarila> there's no way to define a human readable string of a column name in SQL for a reason
<SahAssar> BTW, couldn't this be solved if we actually use the string for those translations and not the key? I get it's a step back in terms of wanting to go over to key based translations, but we only really want to translate "Pages" to "Paginas" the the string is actually "Pages", right?
<SahAssar> If the user changed it from "Pages" to "Pages with bullshit here" We would want their string to show, right?
<rarila> SahAssar: no, the problem is, where he changes it. Having two location to do it makes no sense
<SahAssar> rarila: Well, we have 1+N locations either way since it will be changed in contenttypes.yml and each of the locales used, right?
<rarila> SahAssar: we turn in circles… it makes no sense to have that stuff in ct.yml
<rarila> SahAssar: there's not even one hint in that file what language it uses
<gawainlynch> More importantly, how are we defining the standard for "user" configuration 
<gawainlynch> We should aim to be broadly consistent 
<rarila> and that can only be acchieved by separating data definition and presentation
<SahAssar> It also makes no sense to make people edit translation files to change a contenttype name... I feel like I'm not understanding what you or bob or anyone else want to do with it, and I've read through these threads a few times over the last year. Maybe I'm just being dense, but I'd like to see a proposal and a pros/cons list.
<gawainlynch> SahAssar: Doesn't this work together with your concept of "levels" of available configuration?
<gawainlynch> Because looking at it, it is pretty messy now in that way
<SahAssar> gawainlynch: levels of configuration is perpendicular to translations, not along the same "axis"
<rarila> SahAssar: theres the difference of how the "table" (to say it with sql) is named internally and how this name is displayed to the user
<gawainlynch> SahAssar: You're losing me contextually here
<SahAssar> gawainlynch: well, a backend dev might have full access to the config, but might still prefer to have his contenttypes translated. Those concepts aren't necessarily linked.
<rarila> SahAssar: no "name" and "singular_name" should be in there in ct.yml - that fails already on the assumption that there only exist single and plural – AFAIK e.g. russian has 6 plural forms
<gawainlynch> Yeah, and Symfony's translation engine can handle it . the way we've got it now, we can't
<rarila> yep
<rarila> all those names should be combined into one using this mechansm
<gawainlynch> So the thing is that part of that should be the presentation layer (in these terms), which is either for the dev, or e.g. a chief-editor, to edit … and the config (data) part in ct.yml
<SahAssar> rarila: All I'm saying is that it is odd that changes to contenttypes.yml is not always reflected in the interface. That oddity seems to stem from the fact that we are translating what we apparently assume to be user input without asking.
<SahAssar> (And that we are not using that user input in determining what translation to use)
<rarila> but which one do you expect? contenttypes.entries.name.plural from contenttypes.xx_XX.yml or entries://name: from ct.yml?
<SahAssar> I don't expect those to be translated at all, but if they are I expect them to be translated only if the source string matches the input. If I change the name of 'entries' to 'blogposts' I'd expect it to be called 'blogposts' in cs_CZ, not 'Novinka' which is the translation for 'entries', not for 'blogposts'
<gawainlynch> That I don't agree with … that is mapping hell
<rarila> SahAssar: so you don#t want to localize it at all?
<SahAssar> rarila: I only want to localize when we know the translation.
<gawainlynch> …and for a fallback?
<gawainlynch> …on user content
<SahAssar> If 'entries' hasn't been changed we should use 'Novinka', but if it has been changed we should assume that the dev/user wanted what they put into their config.
<Bopp> still only around-ish, while packing, but I agree with Sahasser. 
<SahAssar> Discarding what they obviously changed for a prebuilt translation seems very, very odd to me.
<Bopp> if I put `label: foobar` in my ct.yml, that is what I want to see on the screen.. Translate that, and it becomes dark magic to the user. 
<rarila> there shouldn't be any lanels, names and so on in vct.yml at all!!!!!!!!!
<SahAssar> gawainlynch: The "fallback" is what they put in their config. If they want to translate it they can put that string in the config.
<rarila> that's the only source of the problem
<Bopp> rarila: yes, of course there should be!
<SahAssar> rarila: Only for the defaults, and they should only be used if the default is unchanged.
<SahAssar> IMO
<rarila> argl
<rarila> we don't even know what language this label in ct.yml is
<Bopp> rarila: and we don't care.. 
<Bopp> if the user puts `label: gdfsgdf` in there, that's what they want. 
<rarila> that way we naver can localize the backend
<Bopp> i disagree.
<SahAssar> No, we don't. But the people who have multi-language backends are the ones who know how to fix it, and the ones that don't are the ones that we are amking go "WTF?"
<gawainlynch> Right … and where are the implementers in this conversation?
<SahAssar> Basically, we are making it harder for newbies while making it easy for the people who know how to do it.
<rarila> SahAssar: we do. How else should I know if I should use the label from ct.yml or when to get a translation?
<gawainlynch> I'm going to have to catch up on this in the morning … my doctor is doctoring
<SahAssar> rarila: If the source string matches the counterpart in the translation we should use it. If it doesn't we shouldn't. See the example with blogposts vs Novinka above
<rarila> SahAssar: string matching may probably work for some languages but don't take that for granted
<rarila> SahAssar: that's why kyes are there
<rarila> words can have different meanings ans so different translations
<SahAssar> rarila: we about fourhundredeleven different issues that might affect languages that neither one of us are used to using or can debug. I say we focus on getting it working as intended for the ones we can before we implement the ones we don't.
<SahAssar> #2247 is one
-[BoltIssueBall]/#boltcms- #2247 [closed] Tags/slugs do not support CJK characters (was: "tagging does not support non-english words") https://github.com/bolt/bolt/issues/2247  — assigned to SahAssar
<SahAssar> We have a number of slugify issues too
<SahAssar> This is one that affects all languages, so making it work seems like a base for working on the rest.
<rarila> SahAssar: nothing to implement, just remove presentation from ct.yml
<SahAssar> rarila: Sorry if I sounded aggressive, that was not my intention. I just don't see any other way to fix this, but if there is I'd be very willing to work on it. These problems aren't new (which you know), I just want to get a fix for it that is agreed upon.
<rarila> SahAssar: why do you use css files? It's much easier to set inline styles. Why do we use external JS with events instead of simple onclicks in html? Why do we code MFC? - there's for sure a reason to seperate presentation from logic
<SahAssar> rarila: Well, css and js is generally not based on visitor preference. Our translation files are.
<rarila> SahAssar: why do we load all that backendstuuff from ct.yml on every frontend page where it isn't needed?
<rarila> SahAssar: don't know how visitor preference come into play here. It's simply a we save one kind of stuff in one place and the other kind in another place
<SahAssar> rarila: Let's play out a scenario. You go into the contenttypes.yml and change the name of a contenttype. That name change is not shown when you reload the page. Are you more or less happy with bolt?
<rarila> SahAssar: it's simply very unlogic to have a few special words (ct names and labels) in ct.yml and the rest for the "main" language (whatever this is) in ct.mainlaguage.yml where for other languages everything is in ct.otherlang.yml
<rarila> SahAssar: in my world there is no name in ct.yml. Ans just changing it there doesn't do the trick anyway as just changing "Pages" there doesn't change e.g. "This Page was created"
<rarila> if you reanem on ct you have to adjust every phrase using it
<SahAssar> I get that, but for that person, who changed the name of "entries" to "news" and sees no change in the backend, how do we fix his problem?
<SahAssar> or her
<rarila> SahAssar: deprecating and removing name/label
<SahAssar> rarila: And replacing it with?
<rarila> SahAssar: with what we already have: contenttypes.xx_XX.yml
<SahAssar> So changing a single label means changing to key in contenttypes.yml and then changing the string in contenttypes.xx_XX.yml?
<rarila> SahAssar: we live in a ajax world, there are more userfriendly solutions possible
<rarila> we can edit contentypes and all tranlations in one editor
<SahAssar> rarila: We don't have those right now though. I'd rather have a CMS that is right in one language than one that is wrong in all languages or will work in all languages in the future.
<Bopp> The last time we had this discussion, I said we should not make decisions on this before we inspect other software. 
<Bopp> It's not a new problem, we'd be fools not to learn from others. 
<rarila> let's make the same mistakes ;-)
<SahAssar> agreed :)
<Bopp> better than making whole new ones
<rarila> that way would still ride on horses instead of driving cars/bicycles
<rarila> +we
<SahAssar> Shit, let's just get some dolphins to ride and we got this all solved :)
<rarila> SahAssar: not a bad idea if you live in an ocean
<SahAssar> rarila: You still around?
<rarila> no, asquared ;-)
<SahAssar> :D
<SahAssar> Anyway, would you mind if I put some user scenarios in 4161 and see what we come up with? seems like if we focus on the technicals we get nowhere.
<rarila> I'm not much interested in that part anymore. Too much frustration on my side
<SahAssar> So you want remove yourself from the decision on that question?
* SahAssar should not have asked that and is going to bed now.
<rarila> It's frustrating to iterate over many good reasons all the time over and over again just to hear "it's uncomfortable, I'm too lazy" all the time.
<rarila> n9 then
<rarila> n8