Tag

PnP

Browsing

Introduction

I recently wrote a post called My GitHub cheat sheet for PnP contributions -- an interactive cheat sheet which explains the GitHub commands that I use when I start a contribution. The post is interactive: you just tell it your GitHub username and what repository you want to contribute to, and it customizes the instructions for you.

I also wrote another post talking about how impressed I am with David Warner II's offer to help anyone with their first contribution.

After briefly chatting with David I realized that the biggest hurdle for people is that they just don't know where to get started. In my post, I recommend that you read the contribution guidelines for every repo, but I found that they are often hard to find in each repository.

I also say that most repositories want you to start from the dev branch, but as the Chris Kent pointed out in yesterday's PnP community call, some repositories prefer you use the master branch.

So, with David's help, we compiled a list of the most common PnP repositories to help you get started.

The list contains the following:

  • Repo: Name of the repository
  • What is it?: Description of the repository
  • Getting started: Links to the most likely resource if you want to get started contributing to that repository
  • Branch: The branch you should target when submitting your pull requests

Please note that the information in each of the repositories can change and that you should always refer to the repository for the latest information.

If you find that we forgot a repository, or that something is wrong, let us know in the comments of via Twitter and we'll get it updated!

Popular repositories

RepoWhat is it?Getting startedBranch
SharePoint/PnP-PowerShellSharePoint PnP PowerShell CmdLets https://aka.ms/sppnp-powershellContribution guidancedev
SharePoint/sp-dev-docsSharePoint Developer Documentation https://docs.microsoft.com/en-us/sharepoint/dev/Contribute to SharePoint developer documentationmaster
SharePoint/sp-dev-fx-controls-reactReusable React controls for SPFx solutions https://sharepoint.github.io/sp-dev-fx-controls-react/- Contribution guidelines
- Submitting a PR
dev
SharePoint/sp-dev-fx-extensionsCode samples and developer content targeted towards SharePoint Framework client-side extensions. http://dev.office.com/sharepointContribution guidanceCreate from:master
Submit to: dev
SharePoint/sp-dev-fx-library-componentsSample solutions from community around the SharePoint Framework library componentContribution guidanceCreate from: master
Submit to: dev
SharePoint/sp-dev-fx-property-controlsReusable SPFx property pane controls - Open source initiative https://sharepoint.github.io/sp-dev-fx-property-controls/- Contribution guidelines
- Submitting a PR
dev
SharePoint/sp-dev-fx-webpartsCode samples and developer content targeted towards SharePoint Framework client-side web parts. http://aka.ms/spfxContribution guidelinesCreate from: master
Submit to: dev
SharePoint/sp-dev-list-formattingSharePoint List Formatting Samples https://sharepoint.github.io/sp-dev-list-formatting/Contribution guidelinesmaster
SharePoint/sp-dev-modernizationAll modernization tooling and guidance http://aka.ms/sppnp-modernizeThe modernization repositorydev
SharePoint/sp-provisioning-serviceCode for the provisioning service hosted at http://provisioning.sharepointpnp.comContributingdev
SharePoint/sp-usage-docsSharePoint Documentation on usage and feature patterns for site owners and citizen developersAdding contentmaster
Sharepoint/PnP-sites-coreOffice 365 Dev PnP Core component (.NET) targeted for increasing developer productivity with CSOM based solutions.Contribution guidancedev
pnp/office365-cliManage Microsoft Office 365 and SharePoint Framework projects on any platform https://aka.ms/o365cli- Contribution guidelines
- Adding a new command
- Submitting a PR
dev
pnp/pnpjsSharePoint Patterns and Practices Reusable Client-side Libraries https://pnp.github.io/pnpjsContribution guidedev

Thanks

Thanks to David Warner II with putting together this list, and for always making yourself available to help people in this community.

This list wouldn't be possible without the hard work of all of those who contributed (and continue to contribute) to the above repositories. Thank you for your contributions!

Photo credit

Image by StockSnap from Pixabay

Updates

  • August 25, 2019: Thanks to Bert Jansen for providing us with details for the SharePoint/sp-dev-modernization repository.
  • August 23, 2019: Erwin van Hunen Tweeted to remind us about SharePoint/PnP-Sites-Core. It is so foundational to other components, I don't know how we missed it. Urgh! I hate to disappoint someone I hold in such high regard! Sorry!
  • August 23, 2019: Waldek Mastykarz rightly pointed out that we forgot the PnPjs repository.

Introduction

I have to admit, I still consider myself a GitHub newbie.

Most of my clients use TFS or Azure DevOps and my previous experiences with GitHub were unpleasant.

But since I started contributing to the Office 365 Developer Community, I had no choice but to become familiar with GitHub.

The majority of the repositories under https://github.com/SharePoint and https://github.com/officedev -- for example -- have contributing guidelines, but they assume that you have a basic understanding of GitHub -- or at least, a better understanding of GitHub than I had when I started contributing.

Because I still hesitate with GitHub commands once in a while, I use a cheat sheet when I start a new PnP contribution. I copy and paste the GitHub commands from the cheat sheet and substitute placeholders with the values I want. It is really an amalgamation of GitHub commands from the various contributing guideline documents I have found useful into (I hope) a coherent set of instructions. I try to use the GitHub browser interface wherever I can, and GitHub commands where it is easier.

I have written this post to answer all the questions I had when I started. It is really a note for myself, but I hope it can be useful for someone else who wants to get started. While this article is written specifically for PnP contributions, they also apply to most open source contributions on GitHub.

I am not a GitHub expert. There may be better ways to do what is described in this post, but these are the instructions that have worked well for me in the past. If you have any suggestions on how to improve the instructions, please submit a comment below. I'll even buy you a coffee when you're in town!

This article focuses on the GitHub commands. If you need help with your first contribution, David Warner II has kindly volunteered to help anyone with their first PnP contribution. He's a true master on the topic.

Note

I'm trying something new today: interactive, personalized instructions for you. Yes, you!

Instead of putting placeholders in the instructions (like [your_repo_name]) that you have to change as you follow the instructions, the placeholders are connected to a form at the top of each section.

When you change the values of the placeholders, the instructions in this post change automatically!

To get customized instructions, just replace the placeholder values with your own values.

Don't worry, we don't save any values you entered.

Let me know if you like this in the comments below. If you do, I may do more interactive posts in the future. It's kinda fun!

Overview

If you know me, you know that I love processes.

The diagram below represents the contribution process that we'll discuss today.

graph LR
AA[Fork repository]-->A
A[Clone repository]-->B[Create branch]
B-->C[Contribute]
C-->D[Push changes]
D-->E[Submit pull request]
E-->|Repeat|B

It consists of the following steps:

  1. Fork repository
  2. Clone repository
  3. Create a branch
  4. Contribute
  5. Push changes
  6. Submit pull request
  7. Repeat (go back to Create branch)

Step 1: Fork repository

Before you can contribute to a repository, you need to Fork it. Forking a repository creates a copy of it from the original owner's account to your own.

Once you have created your own fork, you can freely change the code in your own copy of the repository without worrying about affecting the original repository, or upstream repository. However, GitHub remembers what the upstream repository is, which will make it easy for you to submit your contributions when you're done but also to synchronize changes that have been made to the upstream repository since you forked it.

Forking only happens within GitHub; it doesn't affect the code on your machine (that is, until you clone it, but that'll happen later).

How to fork a repository

  1. In your browser go to http://github.com and find the repository you want to contribute to. For example, the sp-dev-fx-webparts is where you would submit SharePoint web part samples.
  2. In the upper right corner, select the Fork button
    The Fork button in GitHub
  3. If you haven't already logged in to GitHub, you'll be prompted to do so. If you haven't already created a GitHub account, you'll be able to create one. If you have already logged in, it will automatically begin the forking process. You get a cute little animation showing that it is "copying" the repository, and you end up in your own copy of the repository.
    The Forking has begun
  4. You'll know that you're in a fork because the owner will have changed to you, and it should say "forked from ..."
    hugoabernier/sp-dev-fx-webparts forked from SharePoint/sp-dev-fx-webparts

The repository name should now be [your_github_username]/[repo_name], for example, if you forked SharePoint/sp-dev-fx-webparts and your username is hugoabernier, your forked repository will be called hugoabernier/sp-dev-fx-webparts.


Enter your own variables

Take a second to enter the original repository URL and your GitHub username below, and the rest of this post will automatically change to match what you should see:

VariableValue
Original Repository (Upstream)
Your GitHub username

You have created your own fork! This is what is called an origin repository. I know, I know, the terms are confusing, but here is a table that may help break down the differences:

CharacteristicsUpstreamOrigin
What is itThe original repositoryYour forked instance of a repository
Where is ithttps://github.com/SharePoint/sp-dev-fx-webpartshttps://github.com/[your_github_username]/sp-dev-fx-webparts
Who owns itSharePoint (Not you!)[your_github_username] (You)
What changes should you makeCreate issues, submit a pull requestWhatever you want
What is the impact of your changesAffects the original repositoryAffects only your fork
Who can see your changesEveryoneEveryone who looks at your repository, unless you made it private

Once you have forked a repository, clicking on Fork again will do nothing; It simply redirects you to your own fork.

Step 2: Clone repository

Once you created your origin repository, it is time to clone it. Cloning a repository creates a copy of your fork to your local machine, so you can work on it.

The cloned repository, which will reside on your local hard-drive, will become your local repository; The repository that is on GitHub will be what's called your remote repository.

You can make any changes to the local files on your hard-drive, it will only affect your local repository. It won't affect your remote repository (until later, when we push the changes).

To clone your repository

  1. From your computer, launch whatever tool you like to run Git commands. Some people like Git Bash, but I prefer Cmder or the Node.js command prompt.
  2. Make sure that your command prompt is in the directory where you'll want to create your local repositories. I like to use c:\github. You can do so by typing:
    cd \github

    or, if using Git Bash:

    cd /c/github
  3. The repository you will clone will be created a directory within your current directory. To clone the repository, just type git clone followed by the URL of the repository you forked in the previous section. Note that the URL should end with .git:
    git clone https://github.com/[your_github_username]/sp-dev-fx-webparts.git
    

    It should create a directory with the same name as your repo, then should download all the files locally to that directory. It doesn't take very long, but it really depends on your internet connection. This is what it should look like:
    Git Clone in action

  4. Once your local repo is created, change to the directory that was just created by typing cd followed by the repo name and [Enter]:
    cd sp-dev-fx-webparts
    
  5. To link your local repo with the original upstream repo, you'll type git remote add upstream followed by the original upstream repo URL, as follows:
    git remote add upstream https://github.com/SharePoint/sp-dev-fx-webparts.git
    

    Linking to the upstream repo will make your life easier later when you want to make more contributions.

  6. Before you start making changes, you should make sure that you have the latest version from the original upstream repository. Of course, since you just forked the repo, you should already up to date, but if make more contributions later, you'll want to make sure you're always making your new contributions against the latest code. To do so, simply type the following:
    git fetch upstream

Now you'll have a local repository with a remote that is connected to the upstream repo that we can create a branch from.

Step 3: Create a branch

In GitHub, repositories usually have multiple branches. In GitHub, a branch is a way to keep track of change by grouping them into a feature set. The master branch is usually the default branch, where all approved code usually ends up. You normally shouldn't make changes to the master branch directly, that's what pull requests are for.

When you want to make changes in a repo, you should create your own branch to help keep track of the changes you're making. For example, if you want to add a cool feature to a repo, you would create a branch called cool-feature. Meanwhile, someone else may create their own branch called coolest-feature, which may later become the basis for someone else's most-coolest-feature branch.

Eventually, when those branches are submitted via a pull request (assuming they get approved), they'll end up being merged back to the master branch.

Branches in GitHub

Most PnP repositories usually have a dev branch, which is meant to be your starting point for your changes.

Take a moment to look in your repo for any contribution guidelines to make make sure that the starting branch is the dev branch.

To help you, David Warner II and I have compiled a list of popular PnP repositories that will tell you which branch you should use.

Once you have confirmed what branch you should start from, you should create own branch from the starting branch, and give it a name that will describe what you'll be doing in that branch. For example coolerest-feature, or hugo-patch-1. Try to avoid spaces and funny characters.


Enter your own variables

Enter the name of the branch you want to create, and we'll update the instructions for you:

VariableValue
Start branch name (default is dev)
Branch name

To create your branch

To create your branch, follow these steps:

  1. To create a branch, we'll start by calling git pull upstream, which will update your local repository with the latest changes from the upstream repository. We'll also specify which branch to start from, and what to call the new branch by typing the following:
    git pull upstream dev:coolerest-feature
    
  2. Now we'll let your forked origin repo know about the new branch you've created by typing git push origin followed by your new branch name, as follows:
    git push origin coolerest-feature
    
  3. Finally, we'll switch to the new branch you've created by calling git checkout, followed by your new branch name. Type the following:
    git checkout coolerest-feature
    

If you're using Cmder, you should see that your prompt has changed to indicate that you're now in your new branch:
New branch

Note: If you need instructions to configure Cmder to display your repo and branch, read my earlier post

Now you're reading to contribute!

Step 4: Contribute

Now that you have your own branch, you can make the changes you need. Please make sure you follow the Microsoft Open Source code of conduct.

If you aren't sure about the code of conduct, you can also check out the Code of Conduct FAQ.

Once you're done making your changes, you'll want to push your contributions.

Step 5: Push your changes

As you make changes to files in your local branch, your changes will be tracked locally. Changing the files in your local folder does not affect the local repository until you commit your changes.

Once you have committed your changes to the local repository, you can push your changes to your remote repository (the one on GitHub.com).

You can do so by following these steps:

  1. From the local branch folder, type:
    git add .
  2. Commit your changes by typing git commit -v -a -m followed by a comment indicating what your changes were. For example, if you wanted to say "Initial commit", you would type the following:
    git commit -v -a -m "Initial commit"

Now your changes are committed with a comment. Time to submit a pull request!

Step 6: Submit a pull request

In GitHub, a pull request is really simply a request for someone else to review the work that you've done and merge your changes in. When you create a pull request, you need to select two branches on GitHub, the branch that you've made your changes on, and the branch where you would want to merge your changes into.

To do so, follow these steps:

  1. Push your changes to your origin repository (the forked repository you created), you'll want to type git push origin followed by your branch name, as follows:
    git push origin coolerest-feature
    
  2. Once done, use your browser to your forked repository (https://github.com/[your_github_username]/sp-dev-fx-webparts), you should see that your changes have already been reflected to GitHub.
  3. From your forked repository, click on Pull requests in the navigation, then click on New pull request. Optionally, you can visit https://github.com/hugoabernier/sp-dev-fx-webparts/pull/new/coolerest-feature.
    New pull request
  4. You'll be prompted to confirm the branches you want to merge, with an arrow going from one branch to another. Make sure that the arrow is pointing from your branch on your forked repo to the branch on the remote repo. If you follow all the steps above, you should also see Able to merge.
    New pull request
  5. Provide a descriptive title for your pull request. For example, New coolerest feature
  6. Most PnP repositories have a pull request template. Please be courteous and follow the instructions in the template. Follow the prompts and answer as much as possible. If there are sections that say > _(DELETE THIS PARAGRAPH AFTER READING)_, delete them.
  7. When you have filled the template, click Create pull request.

After you've completed your pull request, you'll see that its status is marked as Open

New open pull request

All you have to do now is to wait for your pull request to be merged with the master branch.

It can take a few days, sometimes weeks before your pull request is approved. Please be patient; Most reviewers are volunteers and have a day-to-day job.

While you're waiting, you can start a new contribution!

Step 7: Repeat

If you want to continue making contributions, you simply create a new branch from the original base branch. For example, if you were created the second update to your coolerest-feature, you could call your next branch coolerest-feature-2.


Enter your own variable

Enter the name of the next branch you want to create, and we'll update the instructions for you:

VariableValue
Next branch name

To create your next branch, follow these steps:

  1. Calling git pull upstream with your next branch name by typing the following:
    git pull upstream dev:coolerest-feature-2
    
  2. Push your new branch by typing git push origin followed by your next branch name, as follows:
    git push origin coolerest-feature-2
    
  3. Finally, switch to your new branch by calling git checkout, followed by your next branch name. Type the following:
    git checkout coolerest-feature-2
    

Once your next branch is created, continue contributing as you did before (contribute, push your changes, submit a pull request).

Deleting your branch

Once your pull request has been approved and merged to the master, you can delete your branch. Do not delete your branch before it has been approved -- just in case you need to make a change to your pull request before it has been approved.

Trust me on this one.

Conclusion

I know, this was a long post. However, I hope that it will be useful for someone who wants to get started with making contributions to the PnP community.

For more information

There are many other resources available out there. Here are some that you should definitely check out:

Updates

  • August 23, 2019: Added For more information section, because there are many great references out there that people should know about. Also, added link to the latest list of popular PnP repositories

Photo credits

Branch image by GitHub.
Note image by Pexels from Pixabay

Introduction

Do you find a spelling mistake in the SharePoint Documentation but you don't know how to fix it?

Do you have a cool SPFx web part or extension sample that you think other SharePoint developers would appreciate?

Do you want to add to the PnP reusable controls, PnP property controls, or write your own command for the PnP Powershell or Office365-CLI?

But you never got around to it because you just didn't know where to start?

At the 2019 SharePoint Conference, the always entertaining Vesa Juvonen presented a session about how to start contributing to the PnP community. (I can't find the actual session title or a video of it, but if anyone has a link to it, please let me know).

The whole point of the session was very clear: the SharePoint Development community (or PnP) is open for everyone to contribute.

However, it can be very overwhelming to get started.

Luckily, the community is here to help!

Together, as a community, we can achieve much more than alone.

It is scary for everyone

I'm sure if you asked any of the existing PnP contributors, they'll tell you the same thing: the first contribution is always scary.

Why is it scary? Gene Zelazny who taught me everything about public speaking says that being nervous about speaking in public is a good thing: it means that you respect for the audience.

I think that being scared of making your first contribution to the PnP community is a good thing; it means that you respect the members of the community and you don't want to introduce something that will break a solution, introduce bugs, or lower the quality bar.

That's a good thing!

It doesn't matter how much (or how little) experience you have with SharePoint. Newbies feel that maybe they have nothing new to add, or that it isn't their place to contribute, while more senior developers probably experience impostor syndrome.

If you're worried that you'll make a mistake and make a fool of yourself, don't be. I've written many love letters about the PnP community (here and here), but the fact is: the PnP community is filled with awesome people who will help you. If you make a mistake, they may either fix your mistake for you, or reject your submission, make suggestions to fix it, and kindly encourage you to re-submit.

David Warner II is one of those amazing PnP contributors who goes even further: he'll help everyone with their first contribution!

He recently tweeted this:

If you want to contribute & add your name to the contributors' list, but not sure how I’m offering my time to help! DM me and I will personally walk you thru your 1st contribution in docs! #SharePoint #SPFx #SPC19 #OfficeDev

-- David Warner II via Twitter

If you don't know who David Warner II, he's a prolific Microsoft Office Development MVP who is deeply focused on developing & branding -- two of my favourite topics.

During the day, David is a Managing Consultant at Catapult Systems, but after dark (or whatever spare time he has), he turns into a masked PnP contributor who has contributed to pretty much every PnP repo there is.

Somewhere in between, he also finds the time to write summaries for every PnP community call, complete with screenshots and links.

David Warner II
Come on, how could you not trust this guy?!

I have reached out to David before to seek his advice, and he could not have been more friendly or patient.

So, if you're still afraid to contribute but you want to do so, reach out to him via Twitter.

Paying it forward

The PnP community is so awesome that I feel it is also my responsibility to pay it forward and help.

I'm not a GitHub expert and I still get confused with pull, pushes, branches, commits and pull requests, so I'm not the right person to help you with making your first contribution to GitHub.

However, I'm pretty comfortable with SPFx web parts and extensions; If you have an idea for an SPFx web part that you'd like to build and you don't know where to start, reach out to me and I'll help you start your project and build it -- as long as you promise to share it with the rest of the community as your first contribution.

If the solution doesn't work, you can even blame me 🙂

Conclusion

The Office Dev PnP community is an awesome community that encourages sharing. It welcomes and celebrates newcomers just like you and me.
It can be overwhelming to get started, but the always awesome David Warner II has offered to help anyone get started with a new contribution.

Together, as a community, we can achieve much more than alone.

Welcome to the PnP community. I look forward to your first contribution!

Photo Credit

Photo credit by Esi Grünhagen from Pixabay

Introduction

I love the Office 365 Dev Community.

My career has been dedicated to the IT industry, and I have always been passionate about technology. I've spent a great deal of time sharing that passion with others through my consulting work practice, mentoring, blogging, and various speaking engagements.

Recently, I received a very kind message from someone I worked with many years ago, thanking me for sharing my thoughts and experiences through my blog posts.

When we first met, he was just getting started in IT. He didn't know a lot about programming, but he was smart, driven and humble, and he used those gifts to drive himself to always find a solution. He was tenacious in his pursuits, he had the hallmarks of success.

While we no longer work together, I have continued to check in on him from time to time. I very pleased to see that he is a very successful SharePoint guru who works with some of the most brilliant people I have ever met.

He deserves all the praise for his success and I am happy to have played a small role in that by giving him an opportunity to be engaged, empowered, and to expand his skills.

He did the rest.

The Office 365 Dev Community is one of those online communities that also engages and empowers their members, and gives them the opportunity to expand their skills.

I have already written about the SharePoint Developer Community in my post titled Open Source Contributors are People Too! and talked about how people tend to take the great work the Office 365 Dev Community does for granted.

This blog post explains why I think the Office 365 Dev Community is awesome and why you should consider becoming part of it.

My SharePoint Journey

This blog post isn't about me.

But in order to explain the impact the Office 365 Dev Community has, I need to start with my experience with SharePoint.

Site Server

Many years ago, I had just finished an e-commerce implementation for one of the largest telecommunications providers in Canada using Microsoft Site Server.

During the project, the team and I had to install (and re-install) MS Site Server many times. It was back when installing a server product required us to perform ritual sacrifices to appease the installation Gods or nothing would work.

Site Server came with a sample site called the Knowledge Management site that seemed more appropriate for intranet implementations.

At the same time, Microsoft had a Web Part framework that really consisted of XML, XSLT, and VBScript. It was just a framework on its own that didn't connect with anything else.

By the end of the project, we successfully implemented a cool Knowledge Management instance of Site Server and used web parts in our solution. It was really cool.

Tahoe

My next opportunity came with McKinsey & Company, as a Senior Associate. I was hired in the e-Business Building practice with the mandate of helping the Firm advise their clients about e-commerce technologies, best practices, and their ongoing e-commerce initiatives.

McKinsey was famous (and still is) for their PDNet -- a Lotus Notes-based knowledge-management platform that allows some of their greatest minds to share their research with other consultants within the Firm.

As part of an internal initiative, my team and I were tasked to research Knowledge Management (KM) best practices to see what new technologies, if any, could be used to help improve KM within the Firm.

It was an audacious goal. We had 6 weeks, a small team, and an office in Singapore to prepare a presentation on our findings.

Since we were all e-Business Builders, we thought that we should build a prototype instead of a boring presentation. After all, I had just built a cool KM solution using Site Server.

When we started building the solution, we found out that Microsoft was separating the "Knowledge Management" template from Site Server into a new product called Tahoe; The "Commerce" component of Site Server would become Commerce Server, at least that's how our Microsoft rep had explained it to us.

We received access to an early preview of the product and engaged with two talented MS Consulting (MCS) developers, associates from the Singapore office to get started.

Here we were, two Toronto guys, a few Singapore team members, a Californian (who still thinks that SharePoint is a fad), and a genius webmaster from Helsinki who worked insane hours to build a working prototype of something that would change our lives and our careers immeasurably.

If you don't know the limits of something, there are no limits

Tahoe Server was awesome. It was also the first Microsoft product that came with (almost) the entire library of source code -- because it was all built using VBScript and ASP pages.

I read the entire source code, because I could. And I'm a geek.

We quickly found the limitations of Tahoe Server and since we had access to the source code, we could overcome these challenges and make it do what we wanted it to do.

So, we added the ability for self-service site creation. We indexed Active Directory users to create user profiles with skills matrices (to make it easy to find experts on a given topic). While many of those features became available in SharePoint 2003, we had the opportunity to build our own in Tahoe.

We created our own replication engine to replicate our Tahoe servers between the United States, Australia and Germany, thus making sure that every user would have a fast experience using our portal regardless of where they were in the world.

We even got a little cheeky and added the ability to access the portal with a mobile phone using SMS and/or WAP. Because we could.

When we demoed the prototype in Budapest in front of the entire e-Business Building community, they didn't believe that it was a fully working product. They thought we had people behind the curtains helping us create a fake demo.

Given the success of the demo, we received approval to implement the solution on a larger scale.

Over the next few years, we built more and more functionality for our portal. Tahoe was released as Sharepoint Portal Server 2001. Microsoft flew people from Redmond to Singapore twice to see what we were building. We moved the team to Helsinki, then Munich where our focus was operationalizing our portal.

The first time I went to demo our portal to the team in Munich, I took the first flight out from Helsinki so that I would get there in time for an early morning meeting.

When I got in my taxi at the Flughafen München, I gave the address to the Munich office in my broken German. I had the wrong address and the wrong phone number.

I tried calling people from the Helsinki office to get the proper address, but it was too early and the office hadn't opened yet.

Then, I remembered that I was coming to demo the portal and we had implemented functionality that would allow us to use text messages to query SharePoint using simple messages like "WHO person's name", "WHAT document name", and "WHERE office name". So, with taxi driver waiting and growing impatient, I nervously texted "Where Munich" to our mobile portal.

The response came back within seconds with the right address for the Munich office. I triumphantly gave the address to the driver who immediately said:

"Ah! McKinsey!"

Moving on

Once we were done, the team parted ways. One of the MCS guys moved to MS Corp to build their own version of the portal (eKM/ICE). I moved back to Toronto to build a similar portal for Microsoft Canada.

I continued to build SharePoint portals for three of the top management consulting firms globally and had the opportunity to travel all over the world to do what I loved.

My next challenge was to help architect and implement a large SharePoint service offering for a provincial government -- with over 75,000 users and had the opportunity to implement some of the first and largest Office 365 implementations in Canada.

Shortly thereafter, Microsoft approached me to become a Microsoft Virtual Technology Specialist for SharePoint. In this role, Microsoft would introduce me to their clients as a pretend Microsoft employee to conduct workshops with their clients, where we would build a solution to their problems within less than a day live, and without safety nets.

None of that work would really give me the satisfaction that I really wanted, which was to contribute to the greater SharePoint community.

Until SPFx came about.

SPFx and the Office 365 Dev Community

I was working on a large Office 365/SharePoint project implementing a student portal for a large college. We had specific needs mobile, responsive, and accessibility, that weren't available to us when we started. We chose to integrate the Office UI Fabric by hand into our web parts to give the site a consistent look and feel.

As we built the portal, we discovered that a SharePoint page loaded with dozens of custom provider-hosted SharePoint web parts was insanely slow.

When I found out about this new upcoming SharePoint Framework thingy, it had the promise to resolve many of our challenges and requirements.

Faster web parts, responsive, mobile, accessible, and with built-in support for Office UI Fabric?!?!

Everything I wanted!

Hungry to know more about the upcoming SPFx, my team and I started attending the SharePoint Development Community calls as often as we could.

I was always a Microsoft/.NET guy. I had always dismissed React, Node.js and GitHub as not as good because Microsoft wasn't doing it. Now Microsoft was telling me that the new way to build SharePoint web parts would be to use React, Node.js and Typescript? And in order to find out more about SPFx, I had to use GitHub?!

What the heck, Microsoft?

I had a lot of learning to do.

Fortunately, every Office 365 Dev Community call started with 15-20 minute from Vesa and/or Patrick telling us that we could submit issues and questions in GitHub. Everyone was invited to demo cool stuff they had done. Most calls ended with Q&As that gave us the opportunity to ask questions.

When we asked questions, our questions were given the consideration they deserved. No one was ever ridiculed for their questions. Not from the people hosting the calls, not from the guest presenters, and not from the other attendees.

There were even some calls where we, the attendees, were asked about our opinion!

It was the first time in over 20 years of working closely with Microsoft that I felt that Microsoft was actually listening.

Demoing my first SPFx web part

When SPFx was officially released and supported on SharePoint Online, our portal team had been learning SPFx and eagerly anticipated the opportunity to rebuild most of our web parts to SPFx.

Our project was Agile/SCRUM and we delivered our code in two-week sprints. We dedicated entire sprints to converting our web parts to SPFx, forcing everyone to jump in the deep end.

We quickly found what worked and what didn't. Some SPFx web parts never saw the light of the day, and some others were easily converted. We even rebuilt one web part that took a few months to build over a weekend!

When we demoed what we had done to our Microsoft reps, they asked us to do the same demo to other colleges and universities.

Armed with demoable web parts, I accepted to take Vesa and Patrick's invitation to contribute to the SPDev calls seriously. I sent an insanely long email to them (I wasn't actively using Twitter) and offered to demo some of the web parts we had done.

That was one year ago today.

I didn't expect to hear back from them. And I didn't, for about two weeks. It turns out that cool people don't use email.

Eventually Vesa sent me a response and I was scheduled for an upcoming call. My demo went okay, however the response from the attendees was amazing! I had people reaching out to me to find out how I had done this or that. Some people wanted me to share my code.

What value could I add to the community, except for some cool web parts? I thought that I didn't have anything worth blogging or tweeting about.

Contributing to the community

When I said that to a friend of mine, someone who I respect immensely (except, maybe, for the fact that he insists on sprinkling Salt & Vinegar seasoning on his popcorn), he explained that while I may not feel like I have anything of value to share with others, there are others who are just starting with SharePoint and SPFx who may benefit from my sharing what I have learned thus far, with them.

With this in mind, I wrote an SPFx sample to help others with some of the problems I had experienced when I started learning SPFx, and submitted it to the Samples repo. It was nothing amazing or earth-shattering, it was just a simple example of how to solve a small problem.

My sample got accepted.

Then I demoed it on a call.

And I found that, as my friend with the nasty pop-corn habit had predicted, other people did benefit from my contribution.

I built more samples based on solutions to challenges I had encountered when I started with SPFx and submitted them. They were always graciously accepted. Every time I demoed one of them, the community was always insanely supportive and kind.

Gaining confidence in the community, I wrote some PnP reusable controls that I wished were available, fixed some mistakes in the documentation, and added a very small command to the Office365-CLI. (In fact, my RichText control was just released today!)

No matter how small my contributions were, they were always welcome.

Any time I wasn't sure how to contribute, there was someone who was willing to help. If I made a mistake, nobody made me feel small or insignificant.

Everyone was always gracious and supportive.

Most of my career now has been spent being passionate about SharePoint, and I had finally found a place where other people who are just as passionate congregate and help each other.

Engage, Empower and Expand

That "kid" I hired over ten years ago became an expert because of his hard work. He took the opportunity to get engaged in our company and did great. He was empowered to make a difference and he did, beyond expectations. He was able to expand his skills and responsibilities beyond what (I suspect) he even believed he could, to become the best version of himself.

The Office 365 Development Community gives each of us the ability to do the same.

The various bi-weekly and monthly calls, videos and presentations engage us.

We are all empowered to do demos, create samples, contribute to the many repos out there. You don't have to be an MVP, to know someone at Microsoft, or to be an employee of a big company to participate.

We can all expand the capabilities of SharePoint/O365, and supporting tools by submitting feedback, creating new components, command-lines, tools, web parts, and more.

We have the opportunity to make SharePoint the best platform by collaborating together!

Welcome to the Office 365 Dev Community

If you would like to find out more what's new in the SharePoint development space, you should visit the SharePoint Developer Community (SharePoint PnP) resources. You'll find videos, blog posts, and social media resources that will help.

If you'd like to meet other people who are passionate about SharePoint development, consider attending one of the various community calls.

If you want to see what other people in the community have done, or if you want to contribute, visit the list of open-source projects.

Every single one of us in the Office 365 Dev Community started as a newbie at some point. As long as you do the same, everyone will treat you kindly and with respect.

Every one of us has something important to say for someone else. We all have different backgrounds, experiences, and industries that make us unique. As long as you don't act like you know better than everyone else, and you don't try to sell anything, people will listen.

As long as you genuinely want to share with the rest of the community, not for the purpose of self-promoting, people will appreciate your contributions.

We've all had project deadlines and demanding customers, and we understand the pressures that you're under when you ask for help. We're also under the same pressure, but someone will surely try to help you if you need help.

Welcome to the Office 365 Dev Community. I think you'll like it here.

Conclusion

My SharePoint journey has been a long one. At times, I felt more like a crazy person on a soap-box telling those who didn't want to listen to how awesome SharePoint is.

Maybe I am such a crazy person, but the Office 365 Dev Community is filled with other crazy people who feel the same way.

To all of you in the Office 365 Dev Community, thank you for being awesome and supportive.

I'm proud to be one of you.