RFC: FAST Project Re-alignment #6955
Comments
janechu
added
docs:rfc
|
FAST SSR stays? Are there plans to improve/document that one? |
FAST SSR stays, still in pre-release, it needs some love and we'll have to determine what next steps are. As for documentation, right now it will just be |
|
In general, I think this goes against what is written down on #5901. While it does include a disclaimer that everything in the future is speculative, I didn't expect it to get completely flipped upside down and go against the speculation there. (It should probably be unpinned) I would like to indicate that our team decided to use FAST simply because Foundation existed which allowed us to start our development faster, we have not outgrown foundation as it is still relevant for us. Where we did start developing our own components we we're able to learn from foundation and solve common implementations. I am interested in what the future holds for fast-element and how it will differentiate itself from its "competitors", as in my opinion Foundation was that differentiator. |
|
@Patrickroelofs I think this has been the struggle of the last couple years with priorities for the project (hence the reason our prerelease has been delayed by a few years), also sorry about the conflicting messages there, I have unpinned the issue but left it open and pinned this one. You're right that we originally wanted foundation to be an accelerator for teams and considered it a core priority for a long time, and we still believe in the concept and the problems it solves, having the solution be part of this project is not what we believe the answer to be going forward. This is why we are looking for outside contributors to take on the goals of package and build on it, potentially creating multiple projects. We would also love to showcase the work of other projects that build on The |
|
I understand the idea of making Foundation a community effort, and would gladly pitch in but I have no experience with contributing to open source projects so I would not take a leading role. I do wonder what the plan is with the Design Tokens system which is defined in Foundation, I find this to be an integral part of FAST and it should probably stay with the team if this is possible and the team agrees. I also hope the documentation will be improved as currently I find it very difficult to learn everything I need from the documentation and this is where foundation filled the gaps. |
# Pull Request ## 📖 Description With #6955 we no longer need this section of the PR template. ## ✅ Checklist ### General <!--- Review the list and put an x in the boxes that apply. --> - [ ] I have included a change request file using `$ yarn change` - [ ] I have added tests for my changes. - [ ] I have tested my changes. - [x] I have updated the project documentation to reflect my changes. - [x] I have read the [CONTRIBUTING](https://github.com/microsoft/fast/blob/master/CONTRIBUTING.md) documentation and followed the [standards](/docs/community/code-of-conduct/#our-standards) for this project.
I believe that there are a few folks who are interested in continuing supporting the foundation package, including the design token implementation, specifically the Adaptive Web project (@bheston) and I believe @radium-v (current code owner). Ultimately, I think that both of those packages work well together and I don't think it makes sense to break out the design tokens at this point in time. Of course, there is also the opportunity for other folks to pick up variations or improvements of the package, etc. In terms of Microsoft's investment in the token implementation itself, it's not currently something that is being actively investigated as there is an alternative approach for tokens for Fluent UI, Microsoft's design system. That specifically makes it difficult to prioritize the work and keep things rolling and evolving in a direction that supports the community. I think that were it to be retained within the FAST project, it would likely receive less attention than it would from a community invested in its evolution. I'd also expect that documentation would likely improve for FAST Foundation for the same reason. I know that @radium-v is interested in making some changes to leverage ElementInternals for native form association and @bheston has pretty much finalized the approach for a consistent structure of the components, etc. In terms of FAST Element documentation, @janechu is working on improving that now, evolving the homepage and getting up docs for both FAST Element v2 while maintaining the current v1 release docs. |
Where would this be happening? I'm interested in the latest/greatest in terms of implementing form elements. |
You can check out some of the recent commits to the web components package in fluent ui: https://github.com/microsoft/fluentui/tree/master/packages/web-components |
…6972) # Pull Request ## 📖 Description This update to the docs: - Re-aligns docs around `@microsoft/fast-element` - Adds more docs around the `html`, `css` and `FASTElement` exports ## 👩💻 Reviewer Notes There are 3 `TODO` marked documents that require separate PRs and reviews: - DI (Dependency Injection) - Migration (from `@microsoft/fast-element` v1 to v2) there may not be any breaking changes but there might be some suggestions for users looking to update their package - Component library - with #6955 we are looking to assist the community in the creation of packages built on the `@microsoft/fast-element` package, this should provide some best practices and guidance on doing this. ## ✅ Checklist ### General <!--- Review the list and put an x in the boxes that apply. --> - [ ] I have included a change request file using `$ yarn change` - [ ] I have added tests for my changes. - [x] I have tested my changes. - [x] I have updated the project documentation to reflect my changes. - [x] I have read the [CONTRIBUTING](https://github.com/microsoft/fast/blob/master/CONTRIBUTING.md) documentation and followed the [standards](https://github.com/microsoft/fast/blob/master/CODE_OF_CONDUCT.md#our-standards) for this project. ## ⏭ Next Steps - Fill in the `TODO` docs in separate PRs
FAST Project Re-alignment
The FAST project currently has a number of stated goals and packages that have grown over the course of development. Many of these packages are either unrelated or only slightly related to the core goals of the FAST project and as such are no longer actively maintained.
These packages may still provide value to the open source community, as such we are opening the conversation to determine if anyone is willing to take on and maintain the packages outside of the FAST project.
FAST Project Core Goals
The stated goals of FAST are as follows:
List of Packages
The packages that the FAST maintainers has deemed as non-essential to the project are listed below, please follow the links for the individual package issues to provide feedback:
fast-tagged-templates@microsoft/fast-benchmarks@microsoft/fast-colors@microsoft/eslint-config-fast-dna@microsoft/fast-react-wrapper@microsoft/fast-web-utilities@microsoft/fast-foundationTimeline
We will give the community what we consider a reasonable timeframe of 2 weeks to start discussion on maintaining packages, with a flexible end date depending on how conversations resolve.
Resolution
Once a resolution has been reached for each package, we will deprecate the package and remove the package from the repository.
We will also provide a link in the upcoming documentation update that refers to the package and links to the RFC for that particular package.
Future
The core focus of the FAST project will be on the
@microsoft/fast-elementpackage. We will be making changes to the documentation to reflect this re-alignment and we ask the community to be patient with us as we make these changes to the project.The text was updated successfully, but these errors were encountered: