Jamulus
Replies: 3 comments 43 replies
-
|
Many thanks for this. The release checklist was probably a bit complicated because we needed to discuss and modify it as we went along. Maybe future releases won't need to be quite as granular (or will be more automated). Don't forget also that the Tracking Project was only really functional about half way through. I found it useful after that, but I don't know if anyone else was looking at it, As to process itself: we have discussed the idea of creating a "rhythm" of releases based on a fixed time after the previous release (and if this gets late for some days, so be it). This might help a number of things but mainly because translation (while it's a very good thing!) is also a significant factor in our flexibility. Unlike engineers, translators can't postpone to the next release. And the amount of translation per release is also hard to predict (although we can control it to some extent). Such a "target date" system might also help clarify our status overall and help with decisions to "de-tag" if it looks like we'll be giving the translators too much to do or we feel we need a beta release first, etc. Personally, I think we should be a bit cautious about the frequency at first and aim for "release plus 8 week" cycle because we need to give translators at least 2 weeks, based on previous history, and preferably maybe 3. We could also say that beta releases don't depend on translation, so betas would be outside the "target date" cycle and could happen any time (we've not talked much about testing I don't think too ...). EDIT: This may also relate to my frustratingly un-formed thoughts about a road map. We have "triage" stage in Tracking but no high-level criteria for what should be worked on really. A road map might at least help clarify what we think is worth putting effort into now rather than later. But does that imply a "Jedi Council"? Perhaps that's not very FOSS... |
Beta Was this translation helpful? Give feedback.
-
|
When I first got involved with Jamulus, translations came along whenever the translator provided them - frequently long after the English and German from Volker. I think it's a really good improvement - and should get called out as such here - that we aimed to keep the entire release updated across all supported languages. As I mentioned during the process, I'd like to see the translators getting each issue and doing the translations before that issue is closed. The code (or primary documentation, even) changes may already have been merged at this point. So it would mean always having a separate issue that was the "true" tracking point on the plan, with the PR just for the code review -- unless, of course, there was no change to UI display. As an alternative (lighter weight and now I've thought, probably preferable), we may choose to say that unless the translations, where needed, are on the PR, the PR won't be merged. I don't feel comfortable with "dumping" the release onto the translators and saying "OK, sort that out". Being part of the development of a feature seems more inclusive. But I can't speak for the translators, of course! Cycles, rhythm, etc... Not something I'm keen on. KISS should apply. Don't do too much at once. If that means fix immediate bugs plus get the "most ready" feature delivered and nothing else (but including all the docs and translations) every couple of weeks, fine. If we decide that's too often, it's easier to slow down than speed up - just tag a beta and move on. Tools... I used both the checklist and Tracking Project. Finding them was the most frustrating part. Maybe have another repo -- "jamulussoftware/pm" -- where the Compared with what I'm used to at work, both PRs and Issues have far more discussion on them. That all takes place in chat (Slack) or video calls where needed -- but it's a small team where we know who we're working with. I'm just not really comfortable that the tools on Github are exactly designed for being used in the way they're being used. I know we're "closing and moving to discussion" when something is clearly starting to look precarious... Maybe everything should be required to start as a discussion, then a nominated person (by the people in the discussion, agreed by themselves) raises the Issue as those in the discussion have already agreed. I'd rather not have to review every discussion -- I don't have time -- but I do want to see the Issues, to check whether I think they'll have significant impact one way or another. Yes, it may end up back in the discussion getting the issue closed (but at least I'll know that one needs following). |
Beta Was this translation helpful? Give feedback.
-
I'd agree with that. There's a tendency to want to do everything for the next release, which needs to be curbed a bit :-) I can feel that road map thing coming on again...
That's a very good point. Do we have people asking us when the next release will be and what it will contain? Well, er .. no actually. |
Beta Was this translation helpful? Give feedback.
-
I certainly used this as "won't make it into 3.7.0, so it'll be 3.7.1 for now".
Yes, we should agree on how to use that.
I was hoping to be able to use Backlog as the list of things which definitely should be done (at some point). Undecided items should be in Triage. I'm not sure that this is currently the case. Neither am I sure who should do the moving? There are obvious bugs where a single person may decide this with high confidence that everyone on the team would agree. But who gets to decide whether we'd accept a specific feature? I'm not sure if we should require each main developer to comment on each such issue. On the other hand, this needs at least some visibility. Project board column changes don't trigger any notifications, afaik. So if developer A moves an issue to the backlog (and therefore decides to accept the feature), this information will not be propagated to other developers although it should be. I think we should have "Lazy consensus" for that. Let a single developre decide, but wait X (5?) days for other developers to chime in and veto if necessary. I'm still not sure how to use Github tools to document/signal that. At worst, it will have to be a comment "Sounds good, I'd like to have it, let's wait for other developers to agree" (which triggers a notification). As long as this is the case, the issue would stay in Triage.
Yes.
That's not how I hoped it would work (see above). I'm not totally opposed either, but I do have questions if we go that route. For example: How would we commit to getting it into a release? Would this require synchronuos planning meetings? What I'd like:
This approach has the downside that the Milestone completion indicator will only be useful after the code freeze.
This is a different approach to what feature development at work may look like. However, at work there is time to allocate and developers ("contributors") are "forced" to work on the decided features whereas we are dealing with volunteers here. Nothing prevents us to try to get certain PRs in with higher priority. This could be done by individual main developers by reviewing early, making concrete suggestions for improvements and explicitly pinging another developer for the second review. @gene96817 Thanks for your input as well! So we would have to take into account that too many releases may be a problem for people as well. I understand that when looking at my choir. At the same time, I'm eagerly waiting for the fader adjustment feature to become available in an official release. So it all depends on the perspective. Users may still choose to skip a release and just go for the next one. |
Beta Was this translation helpful? Give feedback.
-
I work to avoid discussion of the next release with my users. I want my users to use what we have. No reason for perfect to be the enemy of the good.
Ah yes, so many improvements. It is hard to know they exist and still wait patiently. |
Beta Was this translation helpful? Give feedback.
-
|
Another argument regarding translation handling: If we wanted translators to be able to submit translations without being in a "please translate" phase, we would have to tell them to run |
Beta Was this translation helpful? Give feedback.
-
I'm hoping this will be done in the 3.7.1 cycle. |
Beta Was this translation helpful? Give feedback.
-
Yes, no need for squash/merge for the app as Qt Linguist shows us what's translated/untranslated. It seems like we're bundling app and website translations together here when talking about releases, but I'd argue they're completely different beasts. App translations are relatively trivial, don't amount to more than a few new strings with each new release (unless it's lagged behind) and there's no need to trawl through docs to find the changes as Qt Linguist does it for you. I think an alert a couple of weeks before the release works fine, as @corrados used to do. I wouldn't hold back PRs or releases because of app translations - if they're done in time, great, if not they can get merged into master if/as they arrive. I don't think the odd untranslated menu entry should be a showstopper for anyone. The website, however... most translations are incomplete/lagging behind with outdated information, and my hunch is that this is only going to get worse. The reason is that with every new release, the list of edits just piles up and makes checking all of them an impossible task as old squash/merges fade into the ether. It's not so much the translation work itself (which is a fairly big task in its own right) as the mind-numbingly tedious work of trawling through docs and scanning them for differences between the original in English and the translation, which is what you have to resort to when your language lags by one release or more. I'll raise my hand and admit I should have foreseen this was going to happen and proposed a system that would have made the workflow more similar to that of Qt Linguist, by using a CAT tool like OmegaT (what I use) or GitLocalize (done some tentative testing and may be less intimidating than OmegaT). However, at this point, migrating to either of these translation memory-based systems would involve a considerable amount of work, as existing translations would first have to be aligned (this means sentence-level alignment of existing translated segments, not actually translating everything missing to date - OmegaT can do this automatically with some manual input) to produce a functional translation memory (.tmx) file, and translators would have to familiarise themselves with the tool chosen... In all scenarios (including the current), it's a massive amount of work, which begs the question - have we bitten off more than we can chew? Stagnant/outdated translations will inevitably lead to problems when people start following instructions that may no longer apply. Sorry for veering a bit OT but I think it's kind of tangentially related to the release process. Tl;dr: It'd be interesting to know what other @jamulussoftware/translators think. |
Beta Was this translation helpful? Give feedback.
-
|
Yes. 3 is the client page. |
Beta Was this translation helpful? Give feedback.
-
|
In the case of the ES translation, it's all up to date - it'd be a shame to pull it offline that being the case. I'm fairly confident I can keep it that way - particularly if those 3 documents are the ones that are going to see the most changes and the rest will stay more or less the same. |
Beta Was this translation helpful? Give feedback.
-
|
OK so the only outstanding question is how we selectively remove the language selector from the pages that we're pausing? |
Beta Was this translation helpful? Give feedback.
-
|
@ignotus666 You ain't seen my re-write... :-) But OK if you're OK with that. |
Beta Was this translation helpful? Give feedback.
-
|
I reserve the right to eat my words ;) |
Beta Was this translation helpful? Give feedback.
-
With 3.7.0 released, I think we should check if there are things to improve, especially considering that this was our first release by this team.
This is mainly intended for the @jamulussoftware/maindevelopers and @jamulussoftware/translators, but any contributor or watcher should feel free to chime in. :)
Some things I can think of:
The good
The bad
Now that we know about such shortcomings, it will be possible to work around them. I also think that the learning process and starting to create some automations took some time for the current release, but may be quicker in the upcoming ones.
I'm planning to aggregate everything I can think of here: jamulussoftware/jamuluswebsite#340
All in all, I think it worked really well, but there are always things to improve on. :)
Beta Was this translation helpful? Give feedback.
All reactions