accelerate solidproject.org updates' publishing
Opened this issue · 19 comments
Search terms you've used
https://solidproject.org/ navigation
Is your feature request related to a problem? Please describe.
There are errors on pages like https://solidproject.org/events and https://github.com/solid/solidproject.org/blob/staging/solid-labs.md as well as https://solidproject.org/press (the 2020-06-04 event is presented as "Upcoming" still today). It is impossible to promote the project's web site when it looks like this.
Describe the solution you'd like
The editors in the process need to be notified or keep an eye and be ready to act.
Describe alternatives you've considered
Assign this 'github helpdesk' task to a student, in exchange for a good comment in his/her LinkedIn profile for good professional proactiveness. :-)
Additional context
I need good quality data on the solidproject site for https://gitter.im/cern-solid/community#
Thank you very much!
Thank you @mariadimou - I'll make sure to bring this up in the weekly Solid Team meeting today and try and find a more efficient website editing and publishing process.
Does the process need to indicate a time limit for each step: editing, merging, .. deploying changes on website?
What happens if we go over?
As far as I'm aware, all team members are generally notified about the GitHub activities; issues, PRs.
While the Editors approved recent PRs like:
the current process indicates that the Creators should be approving similar PRs, and need not assign them to Editors:
Spelling, grammar, broken links, and other minor changes do not need to be approved by the Solid Director and can be updated or approved directly in staging by the Creators. Changes larger than that, but that do not significantly alter the website content (such as referencing community activity outside of the website) also do not need to be approved by the Solid Director in order to be applied to staging, as long as they have been approved by one of the Editors.
Yep, I think Creators can ensure that events are moved from "Upcoming" to "Past" by themselves under the current process; the problem is that there is nobody assigned to actually keep track of when an event has happened to make sure the page is up-to-date.
So there are three possible solutions, in order of the amount of work it would take:
- Don't split the lists between upcoming and past events, but simply use a single list sorted by date in descending order.
- Have someone take responsibility of keeping such pages up-to-date.
- Find or write a CMS that can automatically do that.
TL;DR the website process is too bureaucratic, less is more.
Previously, rather than having staging/master and editorial review the Creators were trusted with keeping track of keeping the website up to date as long as it was in line with @timbl quotes and reviewed technical content. If the website content was not in line with reviewed technical content @timbl review was needed for website changes.
What is adding complication is now that so many people are involved in website updates and general Solid communication is that a lot of tailored explanation is needed to be repeated multiple times at each step which is adding a lot of overhead for everyone and slowing things down.
The Editors already have a lot on their plate with specification editing, and adding website reviews seems to be an additional distracting burden that is hard for them to keep up with on time.
Rather than more process and steps with more people, a simplified process with fewer people responsible for website changes that trusted non-editors more would speed things up.
Dear all,
thank you for your comments. I don't know what clarification to add. I just can't believe that the update of the wrong information on page https://solidproject.org/events is not yet fixed! I am trying with 3 different browsers to be sure that the issue is not with my cache. The commit was done last Tuesday.
This is the public image of the project. If it contains badly formatted and wrong info, I can't continue my persuasion work within CERN. Such changes have to be done within seconds. Who, when, what is waiting to actually merge this to master?
Same about my change about the CERN-Solid description in "labs". What, who, when will have a page solidproject.org/solid-labs published with the correct content? NB! this contains the correct content.
These are just examples. Please review the process.
Thank you for your attention
Maria
Hi @mariadimou, in lieu of the structural changes needed to keep them up-to-date, what errors do you currently see? The only error that I'm aware of of which the fix has not yet been deployed is a missing "-" on the events page? Also note that we currently do not link to the /labs page anywhere yet.
That said, the contents I see on the Labs page appears to be in line with what you linked? When I visit https://solidproject.org/labs I see this:
Thank you @Vinnl for the labs.
The error in events is not just the '-', it is also the month. It should be July. It looks not very serious to have recording and slides for an event that didn't yet take place. The commit is from last Tuesday and contains both these edits. Why is it not yet processed?
The fundamental question is why so many people have to iterate so many times for some things so simple..?
Thanks again
Maria
Ah I see. I agree with your fundamental question that we need too many people to apply such a simple fix, for which I think Mitzi is taking the lead to get a more streamlined process in place for the longer term. But with solid/solidproject.org#284 deployed I think at least your short-term concerns are addressed, is that correct?
@Vinnl Yes, that's correct. Thank you. You can see on https://gitter.im/cern-solid/community why I could not possibly write the last 2 posts as long as the pages labs and events were wrong. CERN people would just run away from this effort, so valuable to me since 1994...
@mariadimou @paulduplantis @ackuckartz @megoth @Vinnl what are your thoughts on this suggestion to accelerate solidproject.org updates' publishing #222
I have been researching this thread for thoughts and see there are no easy answers here but there are a couple of points brought up that seem interesting to me.
The following point from Maria with CERN seems to be descriptive of the potential problem to address.
There are errors on pages like https://solidproject.org/events and https://github.com/solid/solidproject.org/blob/staging/solid-labs.md as well as https://solidproject.org/press (the 2020-06-04 event is presented as "Upcoming" still today). It is impossible to promote the project's web site when it looks like this.
Ruben's point is it does not appear to be a function of the review process as per below.
These numbers allow us to objectively observe that:
The median review time so far has been 1 hour and 21 minutes.
50 out of 111 PRs (45%) were reviewed in less than 1 hour.
60 out of 111 PRs (54%) were reviewed in less than 2 hours.
78 out of 111 PRs (70%) were reviewed in less than 12 hours.
85 out of 111 PRs (76%) were reviewed in less than 24 hours.
In June and July 2020, 31 out of 35 PRs (89%) were reviewed in less than 24 hours.
Two of those were reviewed within 2 hours of assignment (solid/solidproject.org#216 (review) and solid/solidproject.org#233 (review)).
One did not require editor review according to the process (solid/solidproject.org#283 (comment)).
One was missing details from the contributor and took 4 days (solid/solidproject.org#271 (review)).
As such, I round this up to 31 out of 32 (97%) timely actions taken.
Therefore, response time does not appear to be as much of a factor in driving the problem so it seems what would remain to be addressed is the process of accessing the issues and implementing the solutions. As @RubenVerborgh mentioned, these tasks are carried out by volunteers so expectations are different than with a paid team but I wonder if there may be an opportunity to address the concerns with the team to see what they come back with, then build a training protocol and a restructuring of processes around the findings.
I have worked around implementing processes within teams for many years and know there is never a magic bullet. It is about digging deep to see where the problems lies. Not as a means of blame but a desire to provide the team with the proper toolset and information to be successful. I would be more than happy to volunteer some of my time to help if you don't have the bandwidth to dig.
All I know is the public facing side of Solid seems to be a very important component in this next stage of development with Solid as you start to deploy what you have been working on for YEARS. And with this, the team behind the public facing side of Solid will become more important in my estimation. Whether they are volunteers or paid employees, any investment you make in the quality of the time they spend on your project, the better off you will be. In my humble opinion.
Thanks to @paulduplantis for concrete figures and good advice in the above comment.
And thanks to @RubenVerborgh for reminding us here that one should be careful with fora like this, visible to the entire world.
Being very enthusiastic for Solid and in Sir Tim's spirit of the web as a free, open, networked medium I would suggest to contribute (and accept) feedback with a sense of measure.
Technically, all content contributors to the project's public web site, could have a dev instance to see the effect of their changes before merging into master by themselves, without delay. If these content contributors are limited in number and trusted, the potential errors would only be syntax and/or format and fixable, while still in dev.
Managerially, if the above is too scary or restrictive, Inrupt could employ someone responsible to process updates of the public web site faster. Or the collaborating institutes could use a permanent part of students' time to keep an eye on public pages' updates. The latter would require some kind of official assignment or rota, that could be an overhead...
Thank you for your attention and the effort to make Solid known and respected.
@paulduplantis what is the source of the data you generated?
If the time between submitting a pull request and reviewing it is so fast is there a need to accelerate solidproject.org updates at all?
Thanks to @paulduplantis for concrete figures and good advice in the above comment.
And thanks to @RubenVerborgh for reminding us here that one should be careful with fora like this, visible to the entire world.Being very enthusiastic for Solid and in Sir Tim's spirit of the web as a free, open, networked medium I would suggest to contribute (and accept) feedback with a sense of measure.
Technically, all content contributors to the project's public web site, could have a dev instance to see the effect of their changes before merging into master by themselves, without delay. If these content contributors are limited in number and trusted, the potential errors would only be syntax and/or format and fixable, while still in dev.
Managerially, if the above is too scary or restrictive, Inrupt could employ someone responsible to process updates of the public web site faster. Or the collaborating institutes could use a permanent part of students' time to keep an eye on public pages' updates. The latter would require some kind of official assignment or rota, that could be an overhead...
Thank you for your attention and the effort to make Solid known and respected.
I wanted to let you know Maria the data pull is Rubens, not mine. (I only quoted him for context in my reply) I am not a dev with Solid. Just an observer. Personally, I feel this issue is not resolved but again I am just an observer.
@paulduplantis what is the source of the data you generated?
If the time between submitting a pull request and reviewing it is so fast is there a need to accelerate solidproject.org updates at all?
@Mitzi-Laszlo, I stated I felt the issue is not in speed or even the review in of itself. I believe the problem might lie in how the editors are able to manage the requests coming in. It appears to currently be an either Yes or No scenario as opposed to this one is hot - this one can be scheduled for later. I thought @RubenVerborgh had tagged you in my response to this.
To be honest I am a bit confused with this process of discovering a problem to reveal a solution. To me the arc of this entire thread is you need to apologize to the volunteers. Hate to pick sides here but I still don't know what for and why this is even relevant?
Just to let you guys know I have talked to a developer who was building off Solid who has chosen for now not to and one of his comments to me reflect the core of what I am seeing unfold. You seem divided. Not just on this small issue either. I love with all my heart what you are trying to do but I am a bit worried from what I have observed over the last year on Github.
I am launching my Podcast soon and will start to dig into the promises and the realities of trying to build a better web. Solid is a substantial piece of what I will be arguing for so I hope Solid finds their true North through all of this noise.
I met @timbl at the Douglas Engelbart 50 year anniversary Symposium and had such a good feeling about the path he was on. I actually believe he deserved the standing ovation not Ted Nelson. But any road to progress is littered with potholes, I get that. Actually your task is Herculean so I am very impressed you have made it this far.
Anyhow, food for thought and one not made out of judgement but more out of concern.
To me the arc of this entire thread is you need to apologize to the volunteers. Hate to pick sides here but I still don't know what for and why this is even relevant?
Didn't mean to make this the arc; I think the arc is still: what is the actual cause of the slowdown?
Perhaps we should close this thread and pursue that specific topic in #226.I just don't appreciate being called (between the lines even) slow and non-constructive in #222, while I spend every day volunteering on Solid. It's not okay for this to casually happen, and then to be ignored.
Just to let you guys know I have talked to a developer who was building off Solid who has chosen for now not to and one of his comments to me reflect the core of what I am seeing unfold. You seem divided. Not just on this small issue either.
Thanks for sharing this; I think this is a major issue indeed. This thread is indeed exemplary of a couple of things going wrong.
Ruben, I guess I didn't realize you were a volunteer, so in context, you are speaking FOR volunteers. There is so much I don't know about your team, which is why I was fearful for dipping my toe in. Still not sure it was the right decision. Especially for the fact I am not a political thinker and like to get to the bottom of problems regardless of personalities involved. Not a way to make friends ;-) Still say there are tools or processes to help streamline the issues with updating the website. When we assume problems are only human we lose sight of the tools to help humans become better. Kind of what you guys are doing in the first place. Building tools to help people become better at being human. Are you fully utilizing tools for the benefit of your team? There I go again. lol.
I still find my comment of 22 days ago mild and full of collaboration spirit, wherelse page https://solidproject.org/events is totally bogus (future event appears in the past and past event in the future). See screenshot made now:
@RubenVerborgh Already done :) solid/solidproject.org#328
(Maria was notified on Gitter, where this issue was also brought up.)
It seems to me that #227 (merged Aug 3) should have been sufficient to close this (#217, last comment Aug 18) and #226 (last comment Jul 27) ... which ironically are now skewing the mean time taken to resolve Issues and merge or reject PRs in this project.
I also think it worth a bit more focused consideration of an early update to this issue from @mariadimou, toward clarity of future expectations --
Such changes have to be done within seconds.
This seems an entirely unreasonable expectation for a volunteer-powered project, and would be difficult if not impossible to deliver on even in a very well staffed commercial enterprise.
If that is indeed a requirement, at minimum, someone needs to provide funding for at least 4.2 full-time staff (7 days, at 24 hours per day, is 168 hours to be covered; at 40 hours per week per full-time staffperson, that's 4.2 full time staff, to be scheduled in shifts without on-shift breaks, vacations, sick-time, etc.) just to monitor for and apply such "changes [that] have to be done within seconds" -- which requires also that these full-timers have full knowledge and understanding of all material across the site (or at least the pages to which they're dedicated), such that they only apply accurate changes, and do not propagate errors and/or falsehoods, whether intentional (unlikely but still possible here) or not.
I think the analyses applied in the sundry Pull Requests and Issues associated with this one (especially in #226) make clear that responses on the Solid Project are really quite quick, overall -- and I daresay, applying the same analyses to other volunteer-powered projects with similarly sized (and even many larger) volunteer pools would find that the response times on the Solid Project are firmly (dare I say, "solidly"?) among the swiftest.