Code <-> Documentation workflow

👨‍💻 Framework Development 📖 Documentation
35

What is the status of this? Is this information available for all the methods yet? Is this somethings that is going to be applied gradually from now on?

Regarding API Reference documentation I finished checking what is going to be the new site for these docs → https://api.frontity.org/

For that review I have applied prettier to all the docs and included that in the pre-commit hook (so prettier will be automatically applied on every commit)

I have also created in the WIKI some Guidelines for API reference docs with the criteria I’ve followed to document every piece of information (syntax, arguments, types, is mandatory, …). These guidelines takes into account the constraints we have for working with gitbook.

Any feedback on these guidelines (how to properly document API) will be appreciated

36

None yet to be honest. We’ll try to make a decision this month when all the dev team is back from holidays (cc: @santosguillamot).

It looks great to me Juanma :slightly_smiling_face:

37

@juanma now that the DevReal team is going to lead the development of the starter themes, I have a question for you: Will you use the same TSDocs standard that we use for the rest of the Frontity packages, or do you prefer to use another comment format/standard?

I am asking because we have our eslint configured to require TSDocs for the theme files, and each time we edit a file we need to add proper TSDocs for the whole file (we are doing it that way to add TSDocs to our codebase progressively). So if you don’t plan to use TSDocs for the starter themes, it doesn’t make sense that we spend time with that, does it?

38

TBH I don’t understand well the issue here :blush:
Can we have a quick meeting at some point so you can explain this to me?

39

Sure, let’s schedule a meeting :slightly_smiling_face:

40

Juanma has decided that they are going to use TSDocs in the themes, so we don’t have to modify what we do.

Also, I have opened an issue to remove all the React imports from the themes (and our packages), but we agreed that we will ignore the Eslint TSDocs errors for that PR, to avoid the need to add TSDocs to all the theme files at once.

Issue: https://github.com/frontity/frontity/issues/668

41

@santosguillamot and I thought this morning that maybe it would make more sense to not open the “doc issue” in each of our PRs, but once all the PRs of that feature have been merged and we are writing the Final Implementation (and creating the demo video) in the FD.

We think we can make a better summary of the feature and the things that need to be documented as part of the Final Implementation, and it would be much more useful for you.

What do you think guys?

42

I agree. :+1: I think this will simplify the understanding of the features to document them

43

Awesome! Let’s try it then as see how it goes :slightly_smiling_face:

44

@juanma, @mburridge: At some point @santosguillamot and I proposed to be the ones helping you to document the next features because we want to understand what you need.

If you still want, we can do that for the Google Ad Manager package.

45

So should we be approaching one of you two and not the developer who implemented the feature when we want to document a feature and need more clarification/information?

46

@luisherranz @SantosGuillamot @mburridge I’ve tried to wrap up here the resources and conversations we’ve had regarding the documentation, specially those about the workflow for documenting new features

1. Documentation Sites

The main site affected by features documentation is

API Reference

Besides this one, we also manage the following sites

2. Resources

2.1 Which syntax/format to use when documenting API Reference docs

:point_right: Guidelines for API reference docs

in the WIKI of the API Reference docs repo there are the Guidelines for API reference docs with the criteria followed to document every piece of information (syntax, arguments, types, is mandatory, …). These guidelines takes into account the constraints we have for working with gitbook.

2.2 What is the workflow to follow to document a new feature after it’s released

:point_right: Code Releases
:speaking_head: Code <-> Documentation workflow

In the WIKI of the Docs repo is documented the Code Released workflow agreed w/ Dev team to document features after they’re released

2.3 What should be structure of a Feature Discussion to ease the documentation process after the release

:speaking_head: How can we improve the FDs process? → :zap: Mario’s proposal

Regarding this conversation, the most interesting proposal from a documentation point of view is having a Final Implementation section in every Feature Discussion that has been released

From the Final Implementation section proposal I’ve marked w/ :raising_hand_man: those that are most interesting for DevRel for features documentation

Final implementation

  • :raising_hand_man: Pull Request → Link to the PR where it was implemented.
  • :raising_hand_man: Requirements → For example, for the @frontity/yoast package, you have to install the Yoast plugin ^14.0
  • :raising_hand_man: Functionalities → List of the final functionalities that were included in the final implementation, with a detailed explanation of each one: how it works, how to use it (install a package? add a new setting?) and a code example/screenshot/quick video if relevant.
  • Out of Scope → List of the functionalities that were finally discarded or slated for a future time. Until we finish the implementation this may change, so I think is good to do a recap here.
  • :raising_hand_man: API changes
    • Backward compatible changes → List of the changes that are backward compatible.
    • Breaking changes → List of the breaking changes and how to migrate your old project.
    • Deprecated APIs → List of the deprecated APIs.
  • Technical explanation → How the feature was implemented. We explain the code
  • :raising_hand_man: :raising_hand_man: Demo → Full video explaining how to use the feature and its functionalities. This can be added afterwards. We could even include a CodeSandbox like we did with the wp comments.

2.4 Are we going to use TSDocs for documenting the code?

:speaking_head: Code <-> Documentation workflow → Yes, as agreed on January 2021

This will affect anyone modifying the code of the themes/packages as these comments are required to pass the PR checking and being able to merge the PR’s

From here we can have a meeting if you want so we can clarify some final points.
For me the key things that would help DevRel to document new features are

:point_up: The creation of. The Final Implementation section and content suggested by Mario
:point_up: Following this workflow:

  • :one: The PRs of that feature have been merged and the Feature has been released
  • :two: The Final Implementation section is added to the FD
  • :three: The type: code release issue is created in the API Reference repo

What do you think?

1 Like
47

Thanks for the wrap up Juanma! Pretty useful :slightly_smiling_face:

In my opinion it seems we are aligned, so I think we can organize ourselves asynchronously. We have already started working with this workflow, but it doesn’t apply to old features. So let’s keep an eye and see what could be improved.

48

Excellent!

I’ve added a link to the wrap up to the Opening Post: Code <-> Documentation workflow

We must remember to update the wiki once we see if the new proposed process makes sense.

Apart from that, my only suggestion is to create a different Template for the Final Implementation, based on the Implementation Proposal template, but with the new questions suggested by @juanma.

The DevRel team will add or remove sections from that Template over time when they start doing real work and learn what they need and what they don’t.

What do you think?

49

Yes, that was our idea.

Actually, maybe you could do it with Mario and the developer who implemented the feature because the idea was that Mario would learn about your needs to incorporate them in our workflow, and the developer answers your technical questions.

What do you think @santosguillamot?

By the way, you mentioned that you wanted to work on the Google Ads Manager package, which was created by David, but you reached Michal, who is the supporter this week.

I guess we have to make a decision about that as well: Should you work with the original developer or the supporter?

In my opinion, it should be the original developer. Actually, sometimes times there will be more than one developer involved, so you should reach whoever wrote the Final Implementation.

50

I don’t fully understand it. We have this Final Implementation template, that is the one Juanma was referring to. It is also here as markdowwn. Do you mean to change it? I agree it will need some iteration.

Yes, sure. I can be there to analyze the process and the developer in charge of the feature to solve any technical question.

I agree it will be better to contact the Developer who wrote the Final Implementation, who should be the one with more information about the feature.

51

Oh, I thought it was Michal because he raised the issue in the docs repo. Also because Michal announced he’d merged it.

Maybe we should have some easy way of identifying attribution.

52

:question: :question: :question: :exclamation: :exclamation: :exclamation: :laughing:

53

That case is strange. Maybe I didn’t write the final implementation because I was on summer holidays? I don’t remember. The one who writes the FI is usually someone who has been involved on the implementation, so reaching the author should be enough. :thinking:

Anyways, for this specific case, yes, it’s better if you contact me instead of Michal. :slightly_smiling_face:

54

Haha, sorry. I meant once you start working on documenting new features again :sweat_smile: