-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
added discovery book triage RFC #759
Conversation
This RFC needs a bit of work to be accurate. Please give me a few minutes to get things corrected and completed. Apologies. |
That's better. Feedback welcome. |
Comment from @sirhcel:
|
Thank you for writing this up. I would prefer to fill the EDB-MB2 (only for MB2, we already have a chapter like that where MB1 is not supported) with the missing EDB-STM content before doing any archiving of EDB-STM. I am fine with just removing support for MB1 and say that MB2 is a requirement. |
rfcs/0759-discovery-book-triage.md
Outdated
[drawbacks]: #drawbacks | ||
|
||
* People with STM32F3V303 and MB1 boards will feel | ||
disenfranchised by the deprecation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think saying they'll "feel disenfranchised" is quite hyperbolic?
We aren't depriving them of rights, anyone with a STM32F3V303 or MB1 can still can still follow the existing docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The drawback is that if the STM and/or MB1 versions of the books are removed, then they cannot follow them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no mention of removing existing books in this RFC
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn't we just keep the existing books hosted/published and "watermark" them to guide to the maintained version for the mico:bit v2? For those who dare to look at the repository, a note in README.md
could provide guidance for in which branches/tags to find the old sources.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Disenfranchised" was surely the wrong word to use here. But I suspect that there are people who want to continue using and teaching with the STM Discovery Board who will be unhappy that we won't be maintaining that book for them.
I thought about keeping the offer for someone to maintain EDB-STM open; if the right person came along to do that I'd be happy to talk to them. But I think it would take a concerted maintenance effort coordinated with the EDB-MB2 effort to keep that book going.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I absolutely plan to keep all current book content available indefinitely, even in unmaintained form. I don't see any upside to removing it, and a lot of downside. This RFC is purely about restructuring, catching up maintenance, and establishing some base that can be readily maintained.
As a newbie about 6 months ago, I headed into the Embedded Rust matrix channel asking questions on where to start. It was recommended to start with the micro:bit V2 and the Discovery book for the V2, and I was provided the link. I'm not sure if I would have found the Discovery book and found that it would be right for learning embedded rust on my own without that guidance, by just searching the internet. So I think for a lot of newbies that might be path to how they find it, through the matrix channel and being provided the proper link to the new book we'll write. I think it's important we don't break links to the old resources, but I wouldn't be overly concerned about it, if it makes it cleaner and more straight forward for newbies to find the new Discovery Book information quickly and have success quickly so they don't lose interest. |
These are all really useful comments, thanks.
Again, thanks for all the comments! I'm dealing with end-of-quarter at dayjob right now, so this is a good time to figure everything out while I still don't have a ton of time to put work into the actual work. |
Thank you @BartMassey. That addresses my concerns. I misunderstood the RFC. |
@eldruin I think I need to add a fourth step to the RFC for publishing, to make things clear. My plan was just to fix up the landing page book to point to an independent published EDF-STM on github.io and leave a link where EDF-STM sat previously. (I'd put a redirect if I could, but I can't see how that would be possible.) That would be easier than fixing up the auto-publishing, if you think that's OK? If you're cool with these plans I'll go ahead and do some RFC updates and we can review again before merging? Thanks for all your help! |
That would lead to the mentioned 404 wall for all existing links but we can do some mitigations. It is generated by mdbook as well so have it under our own control (also, we should first make it look not totally broken). With some trivial javascript we could automatically redirect the user to the new address for the STM book (e.g. if /discovery/f3discovery in url, replace that with /f3discovery and go there). If not doing some clever inter-repo publishing, we can do this:
Opinions? |
I'm not sure I understand the implications of the first plan. Are we trying to make every link into the old STM book not 404, or just the root link? If the first plan involves making a shadow of the book, then the second plan is definitely better. How about we go with the second plan, and you help me with it when the time comes 😀? I'll try to revise the RFC to reflect all this, then have you look at it again. |
Rewrote substantially. Please see #770 for the current version. |
This RFC proposes a plan for triaging the Rust Embedded Discovery Book (collection).