Process Suggestion - Githubissues

Hey @vvasuki, I noticed that you've made a bunch of changes recently (splitting out to a new org, sub-moduling the transliteration maps, etc.). Given that this project is actively contributed to by multiple developers, I'd like to suggest that we open Issues to discuss some of these unilateral decisions so that they become team decisions, or at least team discussions. Also, opening PRs for changes gives us an option to keep up-to-date with the changes so we don't have to reverse-engineer them to the system from reading commits. It is better for the project at large for us to align on an agreed process if we want to encourage developers to contribute. What are your thoughts? (also curious to hear @psvenk's suggestions)

Also, it seems like the master branch diverged sometime ago and now the git history was messed up (old commit hashes no longer match). Was there a force push or a rebase, or did submoduling do that? In general, we should never overwrite git history if we can avoid it.

Was there a force push or a rebase, or did submoduling do that?

Submoduling involved changing git history + force push to remove references to removed files (as suggested by some online guide).

Given that this project is actively contributed to by multiple developers, I'd like to suggest that we open Issues to discuss some of these unilateral decisions so that they become team decisions, or at least team discussions.

I am very grateful to the invaluable contributions of multiple people - we should keep that up.

That said, I don't have the luxury of expecting immediate feedback - this project is no one's primary commitment; and this project only sees rare changes. And, having to wait half a week or more for response dampens enthusiasm and the flow. Submoduling, standardizing maps and tests across projects is a pretty effortful task requiring many hours of staring crosseyed at the screen - something which benefits more from an inspired charge "into the breach" than some calculated and patient move (which ends up being months or years of procrastination per my experiences in other volunteer projects - eg. https://github.com/jyotisham/jyotisha ).

If I had the slightest doubt in my mind about the beneficence of the changes made, I would solicit input as you suggest. If there are any disagreements with what's been done in this case, we can still discuss on this thread and undo things as needed. But the committee-style of working seems to be more a burden than a help.

TLDR is that I trust people far more than "process", which is why after looking at your work, I have both of you full write permissions. Eg. I trust you to push directly into the repo, with the understanding that you will get alarmed by failing tests and fix the code ASAP.

opening PRs for changes gives us an option to keep up-to-date with the changes so we don't have to reverse-engineer them to the system from reading commits.

The same applies here. I love seeing your PR-s -they're good for minor corrections and checking out work of strangers. They should be used to the extant that they don't become a burden (this is partly relative - can vary with person involved).

Hey @vvasuki, thank you for taking the time to explain your thought process!

If I had the slightest doubt in my mind about the beneficence of the changes made, I would solicit input as you suggest. If there are any disagreements with what's been done in this case, we can still discuss on this thread and undo things as needed.

It seems like the main goal of submoduling was just to share the maps with other projects. I generally avoid submodules (and now I will even more with the way it messes up history), but given that the maps won't change very much, it should be fine.

But the committee-style of working seems to be more a burden than a help.

I'd generally agree, and with open-source projects with hundreds of voices, I can definely agree. But the process I was suggesting in a simple application of common best-practices today (which I'm sure you're familiar with) so I'm not used to seeing it as a burden.

I trust you to push directly into the repo, with the understanding that you will get alarmed by failing tests and fix the code ASAP.

I appreciate the trust!

they're good for minor corrections and checking out work of strangers. They should be used to the extant that they don't become a burden

I think the most important thing about PRs is that they are a standard way of avoiding drastic changes, introducing bugs, and making sure that the codebase is as robust as it could be. In fact, I'd argue just the opposite - minor changes might be safe to commit directly; but large, wide-spread changes should definitely be discussed and reviewed. They also give a convenient way to point to a group of commits, the utility of which should not be understated.

In the end, these changes were made and history was rewritten. We can't roll them back. And that is exactly why it was alarming for me enough to open an issue. When large changes can be steamrolled through, it doesn't really inspire collaboration, regardless of how sound the thinking might be. I get a small group pressure-testing an idea, but n=1 changes are inherently of limited perspective. I think I was just shocked with all the changes all at once, but I can see where you're coming from and it makes sense.

On a meta level, I personally contribute to Sanskrit-related open-source projects because I think the Sanskrit language is underserved and the technology that does serve it currently tends to lack polish, professionalism, or general collaboration; especially when compared to other ancient languages (Chinese, Latin, Greek, Hebrew, Arabic, etc.). It is my personal, completely subjective, observation that, for some reason, Sanskrit tends to attract programmers who feel they know best and constantly re-invent the wheel to solve similar tasks. I have noticed this especially with transliteration systems/libraries, Aṣṭādhyāyī implementations, and conjugators. Sanscript.js seemed to be the exact opposite. @akprasad's initial work was excellent, and when it was transferred to the sanskrit org, it seemed like there was a sense of collaboration. My contributions/suggestions have mainly been to "harden"/modernize the project to make professionals feel comfortable contributing -- things like linting, CI/CD, validation, documentation, types, etc. I was inspired by @psvenk's PR #13 refactor to treat the project, not as a feature-complete library of the past, but an ever-improving one of the present. Not to mention, the extremely informative discussion from #20.

My dream would be to see a modern, well-executed, robust library of Sanskrit texts complete with grammatical parsing, etc. (similar to Sefaria, Perseus Digital Library, Chinese Text Project), but I just don't see the cohesion in the (non-academic) community yet. That said, if you know of any ongoing projects, please let me know! So far, I feel that the sanskrit org is the best change of building it so far, which is really why I want to have a collaboration-first approach. I apologize that this is a little off-topic, but I was hoping to give a you a sense of where I'm coming from. I'm eager to hear your thoughts about any of this, but if you feel the discussion is complete, feel free to close this issue.

Hey @vvasuki, thank you for taking the time to explain your thought process!

Ditto!

But the committee-style of working seems to be more a burden than a help.

I'd generally agree, and with open-source projects with hundreds of voices, I can definely agree.

Not sure that's the case - delay matters more to me.

But the process I was suggesting in a simple application of common best-practices today (which I'm sure you're familiar with)

Well it's been years since I left the industry - so I don't know what the "common best-practices today" are. I like adapting best practices provided I agree that they are indeed "best" for us - like automated tests on pushes.

In fact, I'd argue just the opposite - minor changes might be safe to commit directly; but large, wide-spread changes should definitely be discussed and reviewed.

I'm ambivalent here - Not convinced about this as a general rule (cons mentioned in the previous message). Maybe it suffices to announce and go ahead with big changes- discussion and roll-back can happen after the fact as well.

And that is exactly why it was alarming for me enough to open an issue. When large changes can be steamrolled through, it doesn't really inspire collaboration, regardless of how sound the thinking might be. I get a small group pressure-testing an idea, but n=1 changes are inherently of limited perspective. I think I was just shocked with all the changes all at once, but I can see where you're coming from and it makes sense.

I understand your perspective as well. Perhaps the understanding that "all changes no matter how big are provisional and subject to being rolled back upon discussion" will assuage the concern you mention.

Sanscript.js seemed to be the exact opposite. @akprasad's initial work was excellent, and when it was transferred to the sanskrit org, it seemed like there was a sense of collaboration.

Was it ever not in sanskrit org? I am not aware of such a time.

My contributions/suggestions have mainly been to "harden"/modernize the project to make professionals feel comfortable contributing -- things like linting, CI/CD, validation, documentation, types, etc. I was inspired by @psvenk's PR #13 refactor to treat the project, not as a feature-complete library of the past, but an ever-improving one of the present. Not to mention, the extremely informative discussion from #20.

Good - I appreciate that. My personal experience is that I like to contribute to projects where pull requests and issues are promptly attended to. I haven't ever looked at " linting, CI/CD, validation" etc.. I suspect that most contributors share that attitude. " linting, CI/CD, validation" is very good by itself - but I'm not sure it is a collaborator-magnet.

My dream would be to see a modern, well-executed, robust library of Sanskrit texts complete with grammatical parsing, etc. (similar to Sefaria, Perseus Digital Library, Chinese Text Project), but I just don't see the cohesion in the (non-academic) community yet. That said, if you know of any ongoing projects, please let me know! So far, I feel that the sanskrit org is the best change of building it so far, which is really why I want to have a collaboration-first approach. I apologize that this is a little off-topic, but I was hoping to give a you a sense of where I'm coming from. I'm eager to hear your thoughts about any of this, but if you feel the discussion is complete, feel free to close this issue.

Check out @akprasad's email at sanskrit-programmers mailing list and my suggestion there. I feel you might enjoy contributing to his efforts.

Was it ever not in sanskrit org? I am not aware of such a time.

I'm probably mixing things up. I thought it started on https://www.learnsanskrit.org/tools/sanscript/ first.

I'm not sure it is a collaborator-magnet.

Different strokes for different folks haha!

Check out @akprasad's email at sanskrit-programmers mailing list and my suggestion there. I feel you might enjoy contributing to his efforts.

Thank you for the suggestion — I'll take a look!

indic-transliteration / sanscript.js

Process Suggestion #39