1. Bugzilla Harmony has not been released.
2. TDF is funding its release.
3. Website issues at the moment belong in https://redmine.documentfoundation.org/

Please rest assured that we are doing everything we can to maintain and improve our web applications.

(In reply to Buovjaga from comment #1)
> 1. Bugzilla Harmony has not been released.
> 2. TDF is funding its release.
> 3. Website issues at the moment belong in
> https://redmine.documentfoundation.org/
> 
> Please rest assured that we are doing everything we can to maintain and
> improve our web applications.

I'll report this at RedMine instead. Thanks.

(In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #2)
> (In reply to Buovjaga from comment #1)
> > 1. Bugzilla Harmony has not been released.
> > 2. TDF is funding its release.
> > 3. Website issues at the moment belong in
> > https://redmine.documentfoundation.org/
> > 
> > Please rest assured that we are doing everything we can to maintain and
> > improve our web applications.
> 
> I'll report this at RedMine instead. Thanks.

There is no reason to report it. Thanks.

(In reply to Buovjaga from comment #3)
> (In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #2)
> > (In reply to Buovjaga from comment #1)
> > > 1. Bugzilla Harmony has not been released.
> > > 2. TDF is funding its release.
> > > 3. Website issues at the moment belong in
> > > https://redmine.documentfoundation.org/
> > > 
> > > Please rest assured that we are doing everything we can to maintain and
> > > improve our web applications.
> > 
> > I'll report this at RedMine instead. Thanks.
> 
> There is no reason to report it. Thanks.

Why not? I don't see it tracked elsewhere.

(In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #4)
> (In reply to Buovjaga from comment #3)
> > (In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #2)
> > > (In reply to Buovjaga from comment #1)
> > > > 1. Bugzilla Harmony has not been released.
> > > > 2. TDF is funding its release.
> > > > 3. Website issues at the moment belong in
> > > > https://redmine.documentfoundation.org/
> > > > 
> > > > Please rest assured that we are doing everything we can to maintain and
> > > > improve our web applications.
> > > 
> > > I'll report this at RedMine instead. Thanks.
> > 
> > There is no reason to report it. Thanks.
> 
> Why not? I don't see it tracked elsewhere.

Because updating to it immediately when it becomes available is evident due to us funding the work.

(In reply to Buovjaga from comment #5)
> (In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #4)
> > (In reply to Buovjaga from comment #3)
> > > (In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #2)
> > > > (In reply to Buovjaga from comment #1)
> > > > > 1. Bugzilla Harmony has not been released.
> > > > > 2. TDF is funding its release.
> > > > > 3. Website issues at the moment belong in
> > > > > https://redmine.documentfoundation.org/
> > > > > 
> > > > > Please rest assured that we are doing everything we can to maintain and
> > > > > improve our web applications.
> > > > 
> > > > I'll report this at RedMine instead. Thanks.
> > > 
> > > There is no reason to report it. Thanks.
> > 
> > Why not? I don't see it tracked elsewhere.
> 
> Because updating to it immediately when it becomes available is evident due
> to us funding the work.

I don't see why immediacy is relevant. I've never specified a timespan.

(In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #6)
> I don't see why immediacy is relevant. I've never specified a timespan.

What is the relevance of such a ticket, then? Our infra is regularly updating our web applications to new major versions without any tickets being created. They have their own schedule and rhythm, for example with MediaWiki we do not update to every major version, but only when a new long term support version is released. In some cases we might have to wait for some time due to unexpected problems in the build chain, for example we are currently still on Gerrit 3.6 even though the latest is 3.9.

In this case there is quite a bit of urgency to get Harmony deployed. I've been working since 2019 trying to recruit developers to complete the work and it is a relief to finally see it happening.

(In reply to Buovjaga from comment #7)
> (In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #6)
> > I don't see why immediacy is relevant. I've never specified a timespan.
> 
> What is the relevance of such a ticket, then? Our infra is regularly
> updating our web applications to new major versions without any tickets
> being created. They have their own schedule and rhythm, for example with
> MediaWiki we do not update to every major version, but only when a new long
> term support version is released. In some cases we might have to wait for
> some time due to unexpected problems in the build chain, for example we are
> currently still on Gerrit 3.6 even though the latest is 3.9.
> 
> In this case there is quite a bit of urgency to get Harmony deployed. I've
> been working since 2019 trying to recruit developers to complete the work
> and it is a relief to finally see it happening.

In order for those interested and/or willing to contribute to be able to track implementation of a feature. I'll not be any more verbose, because I rather reasonably shouldn't need to explain what a bug tracker exists to provide.

Considering that you state:

“In this case, there is quite a bit of urgency to get Harmony deployed. I've been working since 2019 trying to recruit developers to complete the work, and it is a relief to finally see it happening.”

...I fail to see why we appear at odds regarding tracking the implementation — if indeed, as you purport, there is urgency, then the immediacy is present, and regardless, the desire for implementation is too.

Why *not* have work tracked? Your opinions appear contradictory to themselves, and certainly at odds with how the rest of not merely this Bugzilla instance (see my other filed bugs and their discussions) but all other Bugzilla instances I've used operate.

(In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #8)
> Why *not* have work tracked? Your opinions appear contradictory to
> themselves, and certainly at odds with how the rest of not merely this
> Bugzilla instance (see my other filed bugs and their discussions) but all
> other Bugzilla instances I've used operate.

Because tracking adds overhead, not everything needs to be tracked. If you want to influence TDF staff management, contact the board of directors and give feedback.

(In reply to Buovjaga from comment #9)
> (In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #8)
> > Why *not* have work tracked? Your opinions appear contradictory to
> > themselves, and certainly at odds with how the rest of not merely this
> > Bugzilla instance (see my other filed bugs and their discussions) but all
> > other Bugzilla instances I've used operate.
> 
> Because tracking adds overhead, not everything needs to be tracked. If you
> want to influence TDF staff management, contact the board of directors and
> give feedback.

How is that a better method than a bug? Regardless, I consider this worth tracking, so if it's just your versus my personal opinions rather than an organizational policy, I don't see why it should be considered authorititive.

(In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #10)
> (In reply to Buovjaga from comment #9)
> > (In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #8)
> > > Why *not* have work tracked? Your opinions appear contradictory to
> > > themselves, and certainly at odds with how the rest of not merely this
> > > Bugzilla instance (see my other filed bugs and their discussions) but all
> > > other Bugzilla instances I've used operate.
> > 
> > Because tracking adds overhead, not everything needs to be tracked. If you
> > want to influence TDF staff management, contact the board of directors and
> > give feedback.
> 
> How is that a better method than a bug? Regardless, I consider this worth
> tracking, so if it's just your versus my personal opinions rather than an
> organizational policy, I don't see why it should be considered authorititive.

It is how infra team is handling things so far and the directors have never seen it necessary to change it. Of course you are free to exceptionally open a ticket and I can take it for my own task to update it to avoid infra team having to spend time on it. But if you want to expand this to a new policy requiring the infra team to ticket any and all web app updates, then you have to prepare for a wider discussion.

(In reply to Buovjaga from comment #11)
> (In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #10)
> > (In reply to Buovjaga from comment #9)
> > > (In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #8)
> > > > Why *not* have work tracked? Your opinions appear contradictory to
> > > > themselves, and certainly at odds with how the rest of not merely this
> > > > Bugzilla instance (see my other filed bugs and their discussions) but all
> > > > other Bugzilla instances I've used operate.
> > > 
> > > Because tracking adds overhead, not everything needs to be tracked. If you
> > > want to influence TDF staff management, contact the board of directors and
> > > give feedback.
> > 
> > How is that a better method than a bug? Regardless, I consider this worth
> > tracking, so if it's just your versus my personal opinions rather than an
> > organizational policy, I don't see why it should be considered authorititive.
> 
> It is how infra team is handling things so far and the directors have never
> seen it necessary to change it. Of course you are free to exceptionally open
> a ticket and I can take it for my own task to update it to avoid infra team
> having to spend time on it. But if you want to expand this to a new policy
> requiring the infra team to ticket any and all web app updates, then you
> have to prepare for a wider discussion.

I do believe that what you describe would be best, at least for significant changes obviously worth tracking, but that wouldn't be within the perview of this. If ever I were to decide to take it upon myself to create an issue to discuss that, I would consider my reasoning very carefully, so its description would be more verbose than this issue's is.

Regardless, would you consider taking this issue, as you describe? I would be incredibly thankful.

(In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #12)
> (In reply to Buovjaga from comment #11)
> > (In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #10)
> > > (In reply to Buovjaga from comment #9)
> > > > (In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #8)
> > > > > Why *not* have work tracked? Your opinions appear contradictory to
> > > > > themselves, and certainly at odds with how the rest of not merely this
> > > > > Bugzilla instance (see my other filed bugs and their discussions) but all
> > > > > other Bugzilla instances I've used operate.
> > > > 
> > > > Because tracking adds overhead, not everything needs to be tracked. If you
> > > > want to influence TDF staff management, contact the board of directors and
> > > > give feedback.
> > > 
> > > How is that a better method than a bug? Regardless, I consider this worth
> > > tracking, so if it's just your versus my personal opinions rather than an
> > > organizational policy, I don't see why it should be considered authorititive.
> > 
> > It is how infra team is handling things so far and the directors have never
> > seen it necessary to change it. Of course you are free to exceptionally open
> > a ticket and I can take it for my own task to update it to avoid infra team
> > having to spend time on it. But if you want to expand this to a new policy
> > requiring the infra team to ticket any and all web app updates, then you
> > have to prepare for a wider discussion.
> 
> I do believe that what you describe would be best, at least for significant
> changes obviously worth tracking, but that wouldn't be within the perview of
> this. If ever I were to decide to take it upon myself to create an issue to
> discuss that, I would consider my reasoning very carefully, so its
> description would be more verbose than this issue's is.
> 
> Regardless, would you consider taking this issue, as you describe? I would
> be incredibly thankful.

I can, if you create it in Redmine (registering in Redmine requires manual approval that you have to request via email as described on its front page). However, you would achieve nearly the same result by subscribing via RSS to https://blog.documentfoundation.org/ as we will surely write blog posts about the progress. I would like to write about it as soon as the developer preview of Harmony is released. I am hoping it will be a matter of weeks now.

(In reply to Buovjaga from comment #13)
> (In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #12)
> > (In reply to Buovjaga from comment #11)
> > > (In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #10)
> > > > (In reply to Buovjaga from comment #9)
> > > > > (In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #8)
> > > > > > Why *not* have work tracked? Your opinions appear contradictory to
> > > > > > themselves, and certainly at odds with how the rest of not merely this
> > > > > > Bugzilla instance (see my other filed bugs and their discussions) but all
> > > > > > other Bugzilla instances I've used operate.
> > > > > 
> > > > > Because tracking adds overhead, not everything needs to be tracked. If you
> > > > > want to influence TDF staff management, contact the board of directors and
> > > > > give feedback.
> > > > 
> > > > How is that a better method than a bug? Regardless, I consider this worth
> > > > tracking, so if it's just your versus my personal opinions rather than an
> > > > organizational policy, I don't see why it should be considered authorititive.
> > > 
> > > It is how infra team is handling things so far and the directors have never
> > > seen it necessary to change it. Of course you are free to exceptionally open
> > > a ticket and I can take it for my own task to update it to avoid infra team
> > > having to spend time on it. But if you want to expand this to a new policy
> > > requiring the infra team to ticket any and all web app updates, then you
> > > have to prepare for a wider discussion.
> > 
> > I do believe that what you describe would be best, at least for significant
> > changes obviously worth tracking, but that wouldn't be within the perview of
> > this. If ever I were to decide to take it upon myself to create an issue to
> > discuss that, I would consider my reasoning very carefully, so its
> > description would be more verbose than this issue's is.
> > 
> > Regardless, would you consider taking this issue, as you describe? I would
> > be incredibly thankful.
> 
> I can, if you create it in Redmine (registering in Redmine requires manual
> approval that you have to request via email as described on its front page).
> However, you would achieve nearly the same result by subscribing via RSS to
> https://blog.documentfoundation.org/ as we will surely write blog posts
> about the progress. I would like to write about it as soon as the developer
> preview of Harmony is released. I am hoping it will be a matter of weeks now.

Really glad to hear it coming along. I'll do it in Redmine when I'm granted access if it hasn't already been posted via RSS at that point. Thank you!

(In reply to Buovjaga from comment #13)
> (In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #12)
> > (In reply to Buovjaga from comment #11)
> > > (In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #10)
> > > > (In reply to Buovjaga from comment #9)
> > > > > (In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #8)
> > > > > > Why *not* have work tracked? Your opinions appear contradictory to
> > > > > > themselves, and certainly at odds with how the rest of not merely this
> > > > > > Bugzilla instance (see my other filed bugs and their discussions) but all
> > > > > > other Bugzilla instances I've used operate.
> > > > > 
> > > > > Because tracking adds overhead, not everything needs to be tracked. If you
> > > > > want to influence TDF staff management, contact the board of directors and
> > > > > give feedback.
> > > > 
> > > > How is that a better method than a bug? Regardless, I consider this worth
> > > > tracking, so if it's just your versus my personal opinions rather than an
> > > > organizational policy, I don't see why it should be considered authorititive.
> > > 
> > > It is how infra team is handling things so far and the directors have never
> > > seen it necessary to change it. Of course you are free to exceptionally open
> > > a ticket and I can take it for my own task to update it to avoid infra team
> > > having to spend time on it. But if you want to expand this to a new policy
> > > requiring the infra team to ticket any and all web app updates, then you
> > > have to prepare for a wider discussion.
> > 
> > I do believe that what you describe would be best, at least for significant
> > changes obviously worth tracking, but that wouldn't be within the perview of
> > this. If ever I were to decide to take it upon myself to create an issue to
> > discuss that, I would consider my reasoning very carefully, so its
> > description would be more verbose than this issue's is.
> > 
> > Regardless, would you consider taking this issue, as you describe? I would
> > be incredibly thankful.
> 
> I can, if you create it in Redmine (registering in Redmine requires manual
> approval that you have to request via email as described on its front page).
> However, you would achieve nearly the same result by subscribing via RSS to
> https://blog.documentfoundation.org/ as we will surely write blog posts
> about the progress. I would like to write about it as soon as the developer
> preview of Harmony is released. I am hoping it will be a matter of weeks now.

https://redmine.documentfoundation.org/issues/3715