grammar development with MATRIX and Profiles
arademaker opened this issue · comments
During our (with @leoalenc) work in the Portuguese Grammar, we have started using the sentences from the https://github.com/delph-in/docs/wiki/MatrixMrsTestSuite to test the grammar. Actually, their translations to Portuguese (revised from https://github.com/delph-in/docs/wiki/MatrixMrsTestSuitePt) . Some examples were manually added in the Matrix customization system in the Test Sentences form. Latter, @leoalenc create some more sentences directly in a local file, called my-test_sentences.txt, to avoid the trouble to add them in the form just to have them saved back in the txt file during the grammar generation from the Matrix.
I am now looking for a more efficient way to deal with the test sets. Page https://github.com/delph-in/docs/wiki/MatrixDoc_TestSentences is incomplete, I suppose that profiles is the right way to go, but I am looking for advice on how to use profiles during grammar development and in particular, if there is any special support for profiles in the Matrix or any special way to work with profiles in a matrix-based grammar.
@danflick, any suggestion about how to work with profiles instead of text files during grammar development?
(Maybe related to #17)
@arademaker I think this kind of question is better on the forum, as the issue tracker is for bugs or requests for documentation. When you have an answer, it might make sense to update our documentation to include that information, though.
in the interest of tighter integration, i would not be unhappy with extended use of the GitHub issues interface. i imagine we are free to define our own inventory of labels, so e.g. clarification or advice could well be among them? also, the ability to assign (multiple) people could be useful in some cases. i have used GitHub issues as a kind of discussion board in other contexts (the MRP shared tasks and some of my classes), and (once you buy into the GitHub philosophy of life) i think it can work pretty well.
When I was advocating for starting https://delphinqa.ling.washington.edu/ , I was mainly motivated by the "marked solution" functionality, which I believe GitHub "discussions" also have (not sure about "issues" though). So long as an answer to a question can be clearly marked as "the solution", thus obviating the overhead of engaging with a long thread, I think it will be even better if everything lives on GitHub. Or maybe there are other uses to the forum, we'll see.
@oepen keeping things all together is well and good, but for Q&A kinds of things, the discussions space on GitHub might work better. There's also team discussion spaces (such as for the Participants team). I now count 5 potential places for discussions:
- GitHub issues (on each repository)
- GitHub discussions (on each repository)
- GitHub team discussions (on each team in the org)
- The Discourse forum
- The mailing list
Also, I'm not sure the "docs" repository is the right place for discussions that aren't specifically about documentation and the wiki. Finally, while I'm comfortable here, there are some who would rather not spend more time in a GitHub tab than absolutely necessary and I don't want to hinder participation for that reason (counterpoint: you've never posted to the Discourse site).
To help with the excess of discussion spaces, we can close/lock some, or at least provide some guidance as to their purpose. It's hard to find a past discussion when there's so many places it could be (add to the above list: minutes of in-person discussions on the wiki).
I was mainly motivated by the "marked solution" functionality, which I believe GitHub "discussions" also have (not sure about "issues" though).
Issues can be closed an marked with labels. It's hard to highlight the specific post with the solution though. Some people edit the top post with a link to the comment.
[...] I think it will be even better if everything lives on GitHub. Or maybe there are other uses to the forum, we'll see.
There was also talk of migrating the 'developers' mailing list archive to the Discourse site so it would all be in one place. AFAIK that's not possible in GitHub Discussions.
ah, i confess i was at best passively aware of GitHub discussions. i think @olzama is making an important point, and closing an issue does not at all seem like the best way of marking the solution, indeed. from my point of view, the previous extended uses of GitHub issues were essentially a todo list (for me), so closing was an attractive aspect of that :-). so, let me retract a little: maybe reserving issues for request-like communications is a good policy.
i had not thought of the various candidate contexts on GitHub either, where one could choose to create either issues or discussions. that seems like another important discussion to have, as spreading these out more than necessary feels potentially detrimental. presumably each repository (module, data, or code) needs its own issue tracker, but possibly we could postulate that there is one unified discussion space for all of DELPH-IN?
at this point, i am tacitly assuming that the developers list can be made inactive relatively soon. one option i had considered was replacing it with discussions among e.g. the participants team. we have recently tried on that strategy for the standing committee, and i think there is emerging consensus that we can leave our mailing list behind.
but preserving the twenty or so years of developers archive intact would seem very desirable to me. a cheap option would be to continue to host them through the DELPH-IN mailman site (which i expect to keep operational for the foreseeable future), but that interface is not especially good at e.g. search. it does, however, support navigation by thread.
i am not sure how difficult or hard it will be to import mailing list archives into the discourse site; the mailman mbox files are a pretty standard archiveformat? we are not the first to consider this kind of move, it seems:
I also prefer to reduce our communication channels... but I also posted in https://delphinqa.ling.washington.edu/t/grammar-development-test-suites-and-profiles/692 anyway.
so, let me retract a little: maybe reserving issues for request-like communications is a good policy.
My view is the following. I posted a question because I believe we don't have documentation about it. Actually, the Matrix page in the wiki is incomplete and it can be updated potentially with the feedbacks I can get in this issue. Once I have answers and add them to the wiki, I would close the issue.
In that way, I see the issues here as the right place to post questions that we, in the end, want to add to the documentation.
but preserving the twenty or so years of developers archive intact would seem very desirable to me...
Moving to the GitHub discussions would be nice. Another alternative is to implement or find a tool that can load the mbox files and expose them in a nice search/browse interface.. The mbox files can be saved in this repo maybe.
But I think we have just made a thread hijacking! Can we go back to #30 (comment)? ;-)