-
Notifications
You must be signed in to change notification settings - Fork 167
Add a design index #190
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
Add a design index #190
Conversation
|
Thanks for doing this. Any reason you didn't do the table in markdown? Not sure we have much HTML in the repo. Markdown is easier to edit and diff. |
|
This omits a lot of designs - many do not declare a PM or dev owner. |
Uh... I didnt' realize markdown supported tables directly. I am definitely going to fix this.
Yes, that's true. I used git history to find some owners for some proposals and fix them up. I am going to try and fix up others too. I wanted to get this out for general feedback before I take care of all the details. |
19ccc9a to
3f0eff7
Compare
|
I don't really know the formal roles of many people at Microsoft. I tried to guess their roles and I probably got some wrong. From reading the generated table, I think there might be some improvements we want to consider to the design template:
But we don't have that information in a machine readable way yet. https://openjdk.java.net/jeps/0 and https://www.python.org/dev/peps/ might also serve as additional sources for inspiration. |
|
Re roles: in that table, Claire, Sourabh, Immo, Rich, Kathleen are PM's and the others are Devs. Personally, I don't think it's necessary to distinguish them. We are quite fluid with who does what. Many designs only have one or the other. But I don't feel strongly either way. |
I had trouble trying to navigate designs, so maybe an overview will help others find designs too. Some designs are clearly marked with a title and PM/Dev assignments. Some subdesigns, unfortunately, are marked the same way. So we have trouble finding main vs sub-designs.
Okay. I kept them in the original design files (since the design template asks for it), but the index now just shows Owners without distinguishing who does what. |
|
I'm ambivalent on this. On the one hand, I like the single file for Ctrl+F. On the other hand, it seems it's yet another thing that will go out of sync fast. There are two ways we could address that:
|
|
my 2c. it seems easy enough to keep up to date periodically, and no big deal if it goes out of date for a while. and if nobody likes to fix it - we delete it 😄 |
|
|
||
| **PM** [Rich Lander](https://github.com/richlander) | ||
|
|
||
| // FIXME: do these count as PMs/Devs? |
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.
PM, Dev, Dev, but I don't think it matters
|
|
||
| **PM** [Rich Lander](https://github.com/richlander) | ||
|
|
||
| // FIXME: do these count as PMs/Devs? |
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.
PM,Dev Dev
|
|
||
| **PM** [Rich Lander](https://github.com/richlander) | ||
|
|
||
| // FIXME: do these count as PMs/Devs? |
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.
PM, Dev Dev
|
@terrajobst do you feel the distinction between dev and PM in the template is important? not all documents have both, and even if they do, the roles are blurred. I think the template ought to just prompt for a list of stakeholders or owners, whatever their roles. the key requirement is: include all stakeholders and record who they are! |
Sure, let's try and see
No. In fact, let's change the template and call it "owner". I'll fix that. |
|
@omajid do you feel like a follow up change that merges Dev/PM into Owners? If not LMK and I can do it. |
|
I am happy to do it, but it might take a few days. |
|
I'm late to the review @terrajobst Since we recently started adding documents into |
|
We should probably update https://github.com/dotnet/designs#creating-a-proposal to add a step |
This was suggested here: dotnet#190 (comment)
| | 2021 | [Designs](accepted/2021/statics-in-interfaces/designs/README.md) | [Immo Landwerth](https://github.com/terrajobst) | | ||
| | 2021 | [Requirements](accepted/2021/statics-in-interfaces/requirements/README.md) | [Immo Landwerth](https://github.com/terrajobst) | | ||
| | 2021 | [Scenarios](accepted/2021/statics-in-interfaces/scenarios/README.md) | [Immo Landwerth](https://github.com/terrajobst) | | ||
| | 2021 | [Statics in Interfaces](accepted/2021/statics-in-interfaces/README.md) | [Immo Landwerth](https://github.com/terrajobst) | |
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.
Static in interfaces are split over multiple documents. It is not clear by looking at the index that all these 4 documents are for static in interfaces.
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.
Thanks for catching this! Do you think it makes more sense to have a single entry for "Statics In Interfaces" or should we list the individual sub-designs with a prefix like "Statics In Interfaces": "Statics In Interfaces: Requirements", "Statics In Interfaces: Scenarios" and "Statics In Interfaces: Designs"?
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 recommend just a single entry for these design that are being spread over multiple documents--just pointing to the top-level README for 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.
I think it would make sense to have just a single entry for Statics in Interfaces. The top level Statics in Interfaces doc can have links to the other ones.
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 would opt for a process that can be easily generated with @omajid's update script. Leaving designs out is probably harder than, say, a prefix notation.
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 script uses a heuristic to separate main designs from subdesigns: If the document lists a PM/Dev (soon Owner), then the document is treated as a main (or top-level) design.
For Statics In Interfaces, it sounds like the main design is accepted/2021/statics-in-interfaces/README.md and the rest are the components. If we removed PM/Dev from those documents, the scripts will just ignore them.
(I also think it makes sense to do anyway: there aren't separate Owners for the Design vs Requirements vs Scenarios, are there?)
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.
Alternatively, I can fix the script to ignore a certain level of nesting as sub-designs and only look for top-level documents.
I had trouble trying to navigate designs, so maybe an overview will help others find designs too.
Some designs are clearly marked with a title and PM/Dev assignments. Some subdesigns, unfortunately, are marked the same way. So we have trouble finding main vs sub-designs.
You can see a fully rendered version here.