Re: BPMLOD and string metadata

Yep.

For what it's worth, we've also in the past had experiences such as the 
following with groups that contained people who were previously unaware 
of GitHub:

a. one email list that was moving slowly suddenly came to life once we 
switched to GitHub, and has been very active since.

b. in another group there were indeed people who resisted the move away 
from email because GH was something new and unknown, but eventually they 
realised the benefit and that (GH issues especially) is really easy to 
use, and now the whole group has all technical discussions in GH.

Btw, if useful, i created some simple, picture-based introductions to 
using GitHub issues that i can point you to (for people who were 
previously inexperienced and fearful).

Just mentioning it as an alternative possibility.  I guess we'll see 
what the chairs decide.

best,
ri



Christian Chiarcos wrote on 06/02/2023 16:58:
>
>     Sure.
>
>     I should mention, btw, that this is not a simple matter of open
>     preference – the group should have a strong argument for using
>     emails for technical discussions that takes into account the
>     people outside the group who will interact with it. (Email is
>     typically used for admin related topics, like this one, though.) 
>
>
> I think it's in fact a difference whether a discussion is more 
> strategic or whether it is specific to, say, a vocabulary under 
> discussion or an emerging standard. This discussion here is strategic, 
> indeed. But for the latter case, if it is maintained in GitHub (and 
> most vocabularies from the wider context of this mailing list are, 
> e.g., OntoLex, lexinfo, NIF or the Metashare ontology), *and* the 
> contributors actually engage with it via GitHub, GH issues make a lot 
> of sense. Talking about OntoLex: There are two vocabularies under 
> active development (and several others under discussion), 
> OntoLex-Morph and OntoLex-FrAC, and indeed, we tried to push the 
> discussion into GitHub issues, partially, at least. (I'm actually on 
> your side, here.) But eventually, this wasn't regularly used. And 
> email was neither. Instead, the recent development mostly occurred 
> during telcos and contributions/drafts/samples prepared for these 
> telcos. So, at least as far as OntoLex-Morph and OntoLex-FrAC are 
> concerned, the primary channel of communication are minute documents 
> and the specification itself. That might be a very different situation 
> from i18n, and, indeed, development is relatively slow. But as I said, 
> trying to move the discussions from meetings and minutes into GitHub 
> issues in OntoLex was not particularly successful, so far (although 
> GitHub issues are taken into consideration, discussed in the telcos, 
> and commented with a response in the issue itself -- if they occur), 
> and the OntoLex community has a lot of overlap with the people 
> involved with BPMLOD.
>
> But I guess it also depends on the number of regular contributors. For 
> these both vocabularies the number of regular contributors has never 
> been more than a dozen people, and some of them coming from the 
> humanities (e.g., lexicography, philology), where working with GitHub 
> is unusual even in the first place, not to mention working with GitHub 
> issues. Enforcing such a shift has obvious benefits, but it may also 
> lead to scaring away potential contributors. (Just as a side-note: The 
> development of OntoLex-Morph was originally conducted via Google 
> drive, only, so moving the minutes archive to GitHub in Oct 2021 was 
> already quite an improvement -- but to this day, GitHub acts more like 
> an archive for minutes and samples -- and for the draft spec, of 
> course -- but not so much as the primary platform for discussions.)
>
> Given the cons and pros, that should really be openly discussed, 
> either in the group as a whole or among the chairs, at least. There is 
> a benefit in transparency, but also the risk of losing parts of the 
> user/contributor base -- and developing best practices without having 
> their potential users involved is clearly a bad idea. We cannot really 
> do multilingual linked open data without having the language people on 
> board.
>
> Best,
> Christian
>