Add new working folders for TAG DevEX initiatives #2005
Conversation
danieloh30
force-pushed
the
tag-devex-initiatives
branch
from
84cd745 to
96b12a6
Compare
|
@riaankleinhans can you review and merge this? |
|
LGTM Thanks @danieloh30 !! |
|
@riaankleinhans who else should review this? |
|
@kgamanji , look good to me. Can you please review? |
|
@kgamanji let me know if you have any questions or concerns |
|
@riaankleinhans To fix the DCO issue, I ran "git rebase HEAD~5 --signoff" to follow the guide. But I ended up with the following error: error: cannot rebase: You have unstaged changes. Can you help me fix this? I fixed the DCO for my first push. When I updated the PR, I got this issue again. |
you have some items that aren't in a commit yet - you should see some with You can commit them, undo the changes made to the file(s), or use git stash to temporarily stash / shelve your uncommitted changes and bring them back once you're done with the rebase |
|
@mrbobbytables thx for the heads up. I tried to fix this but no luck so far! ➜ toc git:(tag-devex-initiatives) ✗ git status Untracked files: nothing added to commit but untracked files present (use "git add" to track) I updated the PR once. Those untracked files shouldn't be added to this PR. How do I fix this? |
danieloh30
force-pushed
the
tag-devex-initiatives
branch
from
49e92fa to
d98421c
Compare
.idea/.gitignore
Outdated
There was a problem hiding this comment.
The .idea path should be ignored by putting it in .gitignore under the root path.
|
@ danieloh30 This PR includes many commits from other guys, which is not the intention. Could you please rebase this PR? |
|
As I said, the other changes are included unintentionally when I did the DCO stuff. Honestly I have no clue how to fix this |
Signed-off-by: danieloh30 <[email protected]>
danieloh30
force-pushed
the
tag-devex-initiatives
branch
from
d98421c to
12f3799
Compare
| More specifically, we: | ||
|
|
||
| * Provide guidance and thought leadership on improving developer workflows and experience in cloud native application development | ||
| * Collaborate with TAG Security to improve the developer experience of integrating security considerations into the developer workflow |
There was a problem hiding this comment.
Should be TAG Security and Compliance
There was a problem hiding this comment.
Would also add a point of collb with TAG Operational Resilience, based on the scope above
There was a problem hiding this comment.
Not sure why this is included in the PR. The charter was already reviewed and posted a while ago: https://github.com/cncf/toc/blob/main/tags/tag-developer-experience/charter.md
Nothing changed for this PR that creates new working folders for accepted initiatives
| * Inner/outer loop best practices | ||
| * Observability and debugging from a developer’s perspective | ||
| * Usability, DevEx research, and DevEx metrics across CNCF projects | ||
| * Developer Experience related to emerging technologies and practices, such as Artificial Intelligence (AI) |
There was a problem hiding this comment.
Are there any other emerging areas that could be highlighted? Seems rather focused on AI only
There was a problem hiding this comment.
Not sure why this is included in the PR. The charter was already reviewed and posted a while ago: https://github.com/cncf/toc/blob/main/tags/tag-developer-experience/charter.md
Nothing changed for this PR that creates new working folders for accepted initiatives
| * Engaging with CNCF project maintainers to improve the developer experience and advise on features with the good impact. | ||
| * Cloud Native application excellence | ||
| * Inner/outer loop best practices | ||
| * Observability and debugging from a developer’s perspective |
There was a problem hiding this comment.
This might be an overlap with TAG Operational Resilience. Can this be rephrased to highlight end user experience while debugging?
There was a problem hiding this comment.
Not sure why this is included in the PR. The charter was already reviewed and posted a while ago: https://github.com/cncf/toc/blob/main/tags/tag-developer-experience/charter.md
Nothing changed for this PR that creates new working folders for accepted initiatives
| * Prescriptive mandates on tooling choices or project roadmaps | ||
| * Evaluating or endorsing specific commercial developer tools outside of CNCF projects | ||
| * Replacing or duplicating efforts by other TAGs unless explicitly partnered | ||
| * Any end-user directed activities and initiatives |
There was a problem hiding this comment.
Could you expand on this point?
There was a problem hiding this comment.
Not sure why this is included in the PR. The charter was already reviewed and posted a while ago: https://github.com/cncf/toc/blob/main/tags/tag-developer-experience/charter.md
Nothing changed for this PR that creates new working folders for accepted initiatives
|
|
||
| # Goals | ||
|
|
||
| * Develop shared vocabulary, metrics, and frameworks to evaluate DevEx |
There was a problem hiding this comment.
Metrics also involve a partnership and possible overlap with TAG Operational Resilience. Perhaps aim to identify "milestones" in the DevExp area?
There was a problem hiding this comment.
Not sure why this is included in the PR. The charter was already reviewed and posted a while ago: https://github.com/cncf/toc/blob/main/tags/tag-developer-experience/charter.md
Nothing changed for this PR that creates new working folders for accepted initiatives
| * Charter and TAG page: https://github.com/cncf/toc/tree/main/tags/tag-developer-experience | ||
| * Propose topics, contribute to documents, or join a subgroup on Slack: https://cloud-native.slack.com/archives/C08KGCXB458 | ||
|
|
||
| For more details, visit our GitHub repository and calendar of meetings. |
There was a problem hiding this comment.
Is there a link to the CNCF calendar where the TAG meetings are added?
There was a problem hiding this comment.
Not sure why this is included in the PR. The charter was already reviewed and posted a while ago: https://github.com/cncf/toc/blob/main/tags/tag-developer-experience/charter.md
Nothing changed for this PR that creates new working folders for accepted initiatives
|
|
||
| ## Initiative description | ||
|
|
||
| Improving Developer Experience (DevX) in Cloud Native environments requires more than individual tools, it requires a shared understanding of how developers work, where friction exists, and how to iterate toward better workflows using CNCF projects. |
There was a problem hiding this comment.
Would recommend aiming for consistency in abbreviations. "DevEx" was used in previous docs
|
|
||
| ## Initiative description | ||
|
|
||
| CNCF projects must adopt strong security practices while allowing for a smooth developer experience. This initiative aims to understand both sides of that spectrum. It will identify and document success stories from CNCF projects that have effectively followed TAG Security’s best practices and uncover the pain points and friction that contributors experience when attempting to adopt similar practices. |
There was a problem hiding this comment.
Ditto: should be TAG Security and Compliance
There was a problem hiding this comment.
This context is copied from the original initiative (#1943). Shouldn't we update it first?
|
|
||
| This initiative would set out to create a project-agnostic specification that for declaring a service’s dependencies, so that it could indicate to an application deployment team what other services must be readily available for the application to run successful - e.g. APIs, databases, caches, blob stores, message buses, etc. This is not meant to replace conversations between application engineers and production support. Rather, it’s meant to give them a standardized reference that they can use to enable their discussion. | ||
|
|
||
| I say project agnostic specification because there have been attempts to build this as part of a solution in the past, e.g. Radius. Since the Radius approach packaged the spec in with the solution, the spec has only evolved to the degree that the solution can support it, most notably with a strong focus on Azure services. Making the spec project-agnostic would create a solution-independent language that can be implemented however necessary by conforming projects, including Radius. In fact, this effort would likely look to Radius, Porter, and other projects like them for inspiration. But the benefit of a spec is that it could also be leveraged for other use cases, such as guaranteeing abstraction coverage in Dapr, or for integration mocking in Microcks. Furthermore, it can support security efforts that are focused on expected application behavior, such as Software Bill of Behavior (SBOB) initiatives. |
There was a problem hiding this comment.
Would remove the 1st person addresal. e.g. "the terms project agnostic specification is used [...]"
There was a problem hiding this comment.
This context is copied from the original initiative (#1797). Shouldn't we update it first?
You are mid-rebase and walking through the commits of your PR. You need to to complete or stop the rebase before you can continue. |
@mrbobbytables what git commands do I need to do it? I just noted the charter.md (already reviewed and posted) shouldn't be included in this PR. |
6 participants
Add new working folders for TAG DevEX initiatives