Diaspora Week in Review: Cleaning up
by Sean Tilley on May 14, 2012
Core Development:
Last week, the core team began putting the groundwork together for making our CSS responsive, as well as decoupling post interactions from the actual posts themselves. refactoring the post presenter, and various improvements to our fix our build via TravisCI were made.
Community Development:
Stevenh512 has, as usual, been rocking things this week with development. After fixing Reshares so that they properly pick up the NSFW label, he also contributed an overhaul for cleaner email templates, and added Rails Admin back in to the system.
Raven24 has been working on polishing up the install script even more, to make setting up a test environment as painless as possible.
An improved debugger gem was added to the gemfile by tsujigiri, fixing some of the issues our previous debugger had.
Pubis contributed improvements to our federation logger. It now makes use of matched integration pod ports, and separate dump files, for logging.
BugMash
1. Hashtags Case insensitivity is Broken
Sean: This is probably due to our upgrade to the acts_as_taggable gem, which now reflects the upstream release. There may be something useful you can look into in this tutorial for the gem.
2. Adding long text before @mention breaks mentioned name highlighting
Max: We’re using Jquery Mentions Input http://podio.github.com/jquery-mentions-input/. We’re not exactly sure where the bug is so step one will be reproducing it ;-P. You might want to look at updating this library, but I think we’re on the most recent version
3. Incorrect started sharing notification on Aspect change
Max: Is this only for local notifications? Not sure where to start, but it could be in the way that contacts or requests are dispatched.
(for the record, completely revamping notifications could be a good community task. It would be a lot of work, but worthwhile since notification data is 1) throw-away-able, and 2) completely local.
4. “Show x more comments” deletes text in comment box when clicked
Sean: It sounds like clicking on the link makes an ajax call to show the other comments, but something is causing the textbox to empty itself.
5. The Publisher doesn’t expand after writing more than 30 lines of text
Sean: This is due to the fact that jquery.autoresize specifies a max-height of 500px. The maximum could easily be increased to add more room to the Publisher.
Diaspora Week in Review: It’s the small things that count.
by Sean Tilley on May 7, 2012
A lot of interesting developments came in last week pertaining to showpages and how they work. We looked at performance to improve response times and usability on the show pages, and this also is reflected in the latest designs of the Publisher.
You can check out the following commits to see what the new code does:
- Clean up DOM on Post Viewer
- Next and Previous should be faster
- Next and Last posts don’t have obnoxious blink
- Next and previous post now return posts and json
Community Developments
Raven24 has submitted a new fix for the popular “Back-to-Top” button, so it is now rendered properly in conjunction with backbone.
StevenH is in the process of fixing up the templates for system emails. They’re now much simpler, and should clean up a lot of the output present in some existing email notifications.
The wiki is currently in the state of being cleaned up, with a stronger focus on developer-centric and podmin-centric information. We’re cleaning house, and working on making it leaner and more relevant.
BugMash
1. Adding long text before @mention breaks mentioned name highlighting
Max: We’re using Jquery Mentions Input http://podio.github.com/jquery-mentions-input/. We’re not exactly sure where the bug is so step one will be reproducing it ;-P. You might want to look at updating this library, but I think we’re on the most recent version
2. Resharing a post from a NSFW-marked user removes the NSFW label
Max: This could be solved by delegating NSFW from the reshared message. Reshares are really just wrappers around the original posts, so we need to just define them on the Reshare model and make sure they are exposed via the javascript.
3. Incorrect started sharing notification on Aspect change
Max: Is this only for local notifications? Not sure where to start, but it could be in the way that contacts or requests are dispatched.
(for the record, completely revamping notifications could be a good community task. It would be a lot of work, but worthwhile since notification data is 1) throw-away-able, and 2) completely local.
4. Cannot select more than one Aspect in Stream (in progress, Pull Request Here)
Sean: This is possibly caused by how the Aspects are currently rendered in the stream via Backbone. It might need to be adjusted to be in line with how our current stream is rendered, as this functionality basically amounts to “Render the stream using these aspects as filters”, but currently it only renders the Aspects one at a time.
5. Hashtags Case insensitivity is Broken
Sean: This is probably due to our upgrade to the acts_as_taggable gem, which now reflects the upstream release. There may be something useful you can look into in this tutorial for the gem.
Diaspora Week in Review: Refactor!
by Sean Tilley on April 30, 2012
This week, our codebase took another step forward in its maturation. There’s been a lot of refactoring going on to improve how the current system works.
Community
-Our acts_as_taggable_on gem was updated to the latest stable upstream by Kaushik, who also provided improvements to our English (Pirate) translation! (Yeah, we totally have that!)
-Additionally, Kaushik also optimized the destroy action for following tags.
-Florian refactored our Reshares to now use a flashed message instead of appending a post to the stream. This clears up some of the initial confusion as to why posts visually appeared to be appended to streams and user pages, and is an improvement in usability.
-MrZYX submitted a pull to make community spotlight queries less ambiguous.
-The Documentation refactoring has been going on in full swing. This coming week focuses on improving the installation guides to ensure that they’re fully updated and maintain a standard form of writing across all of them. Some example templates to use for reference are in the works.
Core Development
Much of the development going on in the past week has gone towards our new profile layout, which is coming along nicely. You can track the latest progress of it in the main branch here.
Multi-stream queries have been improved, and a new “Roles” system has been introduced to make use of it. Roles now affect permissions at a controller-level rather than simply residing in the application.yml file.
Additionally, the layout to the new publisher has been improved as well.
BugMash
1. Adding long text before @mention breaks mentioned name highlighting
Max: We’re using Jquery Mentions Input http://podio.github.com/jquery-mentions-input/. We’re not exactly sure where the bug is so step one will be reproducing it ;-P. You might want to look at updating this library, but I think we’re on the most recent version
2. Resharing a post from a NSFW-marked user removes the NSFW label
Max: This could be solved by delegating NSFW from the reshared message. Reshares are really just wrappers around the original posts, so we need to just define them on the Reshare model and make sure they are exposed via the javascript.
3. Back-to-Top Button should appear automatically when you scroll down (Claimed)
Dan: Look at this file. For some reason the correct class isn’t getting applied to the arrow and/or the class is not applying the styles that we actually want.
4. Incorrect started sharing notification on Aspect change
Max: Is this only for local notifications? Not sure where to start, but it could be in the way that contacts or requests are dispatched.
(for the record, completely revamping notifications could be a good community task. It would be a lot of work, but worthwhile since notification data is 1) throw-away-able, and 2) completely local.
5. Cannot select more than one Aspect in Stream
Sean: This is possibly caused by how the Aspects are currently rendered in the stream via Backbone. It might need to be adjusted to be in line with how our current stream is rendered, as this functionality basically amounts to “Render the stream using these aspects as filters”, but currently it only renders the Aspects one at a time.
Diaspora Week in Review: Features, Features, and more Features
by Sean Tilley on April 22, 2012
Community
-This coming week, we’re going to be launching a daily hashtag campaign in which end users can participate by following the DiasporaHQ account on Diaspora. Each day, there will be a new HashTag for users to express themselves with. The idea is to experiment with self-expression beyond the scope of what’s being done with the #NewHere tags.
-Also this coming week is a second call for documentation clean-up. While most of the docs have been updated for Rails 3.1, we want to improve documentation by standardizing how guides and other pages are written. Better information helps lead to making testing and development easier for community developers, and that’s something we want to double down on.
Development
-The new Publisher is nearing completion, as demonstrated by this community video. As demonstrated, users can now express themselves through their content in new, customizable ways through the simple use of templates.
-As mentioned in last week’s Community Code Chat, a lot of great new work is going into the redesign of user profiles. You can track the progress of it in the master branch.
-The Photos stream has been completely rewritten and improved, thanks to Raven for his hard work on making it better!
-An interesting Pull Request sitting in the pipeline shows functionality for Geotagged posts. Thanks to the developer Marco-Gallardo on GitHub for taking his time to put this together.
BugMash
1. Resharing a post appends it to whatever stream you’re on
Max: Again, after you get the success from the post, we may need some basic checking around what URL you are on before adding it to that pages post collection.
Dan: Let’s take out appending reshared posts to streams altogether, and instead have the success response to resharing a post be a flash notification.
In order to do this, modify this line to invoke a Diaspora alert instead of appending the said post to app.stream. (For the diaspora alert object, see this)
2. Adding long text before @mention breaks mentioned name highlighting
Max: We’re using Jquery Mentions Input http://podio.github.com/jquery-mentions-input/. We’re not exactly sure where the bug is so step one will be reproducing it ;-P. You might want to look at updating this library, but I think we’re on the most recent version
3. Resharing a post from a NSFW-marked user removes the NSFW label
Max: This could be solved by delegating NSFW from the reshared message. Reshares are really just wrappers around the original posts, so we need to just define them on the Reshare model and make sure they are exposed via the javascript.
4. Back-to-Top Button should appear automatically when you scroll down
Dan: Look at this file. For some reason the correct class isn’t getting applied to the arrow and/or the class is not applying the styles that we actually want.
5. Incorrect started sharing notification on Aspect change
Max: Is this only for local notifications? Not sure where to start, but it could be in the way that contacts or requests are dispatched.
(for the record, completely revamping notifications could be a good community task. It would be a lot of work, but worthwhile since notification data is 1) throw-away-able, and 2) completely local.
Diaspora Week in Review: Constantly Evolving
by Sean Tilley on April 16, 2012
Hi Community,
It’s another week in, and therefore it’s time for another summary of everything that happened last week. It’s an exciting time for Diaspora, as we’re constantly growing and evolving in new ways.
Development
AppConfig is being re-tooled to be cleaner, more organized, and easier to configure. The pull request is currently sitting in the pipeline for community discussion. (Much thanks to Mr. ZYX for getting the ball rolling on this)
A new Bash Script is in development to make it easier for developers to set up a simple test environment. It is specifically targeted towards getting a test instance of Diaspora up and running easily.
Rails Admin has been pushed into the main branch, making a much easier admin interface for podmins.
Our bootstrap toolkit has now been unified with Bootstrap-Sass, thanks to the hard work of Steven. We now use one version of bootstrap for everything, rather than the multiple versions before.
BugMash
1. Resharing a post appends it to whatever stream you’re on
Max: Again, after you get the success from the post, we may need some basic checking around what URL you are on before adding it to that pages post collection.
Dan: Let’s take out appending reshared posts to streams altogether, and instead have the success response to resharing a post be a flash notification.
In order to do this, modify this line to invoke a Diaspora alert instead of appending the said post to app.stream. (For the diaspora alert object, see this)
2. Adding long text before @mention breaks mentioned name highlighting
Max: We’re using Jquery Mentions Input http://podio.github.com/jquery-mentions-input/. We’re not exactly sure where the bug is so step one will be reproducing it ;-P. You might want to look at updating this library, but I think we’re on the most recent version
3. Resharing a post from a NSFW-marked user removes the NSFW label
Max: This could be solved by delegating NSFW from the reshared message. Reshares are really just wrappers around the original posts, so we need to just define them on the Reshare model and make sure they are exposed via the javascript.
4. Back-to-Top Button should appear automatically when you scroll down
Dan: Look at this file. For some reason the correct class isn’t getting applied to the arrow and/or the class is not applying the styles that we actually want.
5. Incorrect started sharing notification on Aspect change
Max: Is this only for local notifications? Not sure where to start, but it could be in the way that contacts or requests are dispatched.
(for the record, completely revamping notifications could be a good community task. It would be a lot of work, but worthwhile since notification data is 1) throw-away-able, and 2) completely local.
Diaspora Week in Review: Of Rails, Wishlists, Bootstrap, and Bugs
by Sean Tilley on April 9, 2012
Hey, community.
Normally, you’d be expecting a Bug Mash Monday in this place, but we’ve decided to retool things a little in our pursuit of moving forward. We’re growing, and in the spirit of growth, it’s only natural to change for the better. From now on, our Mondays will not only focus on open bugs for the Bug Mash, but also some of the really interesting developments going on in the community that you might not have heard about.
So, what’s going on?
The Big Stuff
First and foremost, we’ve successfully made the transition to Rails 3.1! This brings a lot of cool little benefits to our platforms, and it was a huge upgrade. We couldn’t have done it without the help of Steven Hancock, who put in the long hours to help us transition over.
The Wishlist
In other news, there’s a lot of neat things going on with our Developer Wishlist that we launched the other week. There’s already a ton of things in progress, check them out below!
Keep in mind, just because someone’s working on them doesn’t mean they want all the glory for themselves. If you want to jump in and lend a helping hand, I’m sure they’d definitely appreciate it!
-Steven’s working on unifying our Bootstrap toolkit to be unified with Bootstrap 2.0. We’ve had different versions for different parts of the site, so it’s great
-Email templates are being cleaned up and made simpler, for the sake of more coherent email notifications.
-We’ve gotten past the first stages of developing a Branding Pack for podmins to make pod customization easier. Currently we’re discussing how best to take this forward to make it even easier.
-Our test suite now has Spork integrated! Thanks to Tom Scott for his hard work on making this a reality!
The BugMash:
1. Users not getting “so and so started sharing with you” notifications
Max: Starting with some reproducible tests, and then its back to spelunking in some federation code, which we can discuss on the mailing list.
2. Resharing a post appends it to whatever stream you’re on
Max: Again, after you get the success from the post, we may need some basic checking around what URL you are on before adding it to that pages post collection.
Dan: Let’s take out appending reshared posts to streams altogether, and instead have the success response to resharing a post be a flash notification.
In order to do this, modify this line to invoke a Diaspora alert instead of appending the said post to app.stream. (For the diaspora alert object, see this)
3. Adding long text before @mention breaks mentioned name highlighting
Max: We’re using Jquery Mentions Input http://podio.github.com/jquery-mentions-input/. We’re not exactly sure where the bug is so step one will be reproducing it ;-P. You might want to look at updating this library, but I think we’re on the most recent version
4. Resharing a post from a NSFW-marked user removes the NSFW label
Max: This could be solved by delegating NSFW from the reshared message. Reshares are really just wrappers around the original posts, so we need to just define them on the Reshare model and make sure they are exposed via the javascript.
5. Back-to-Top Button should appear automatically when you scroll down
Dan: Look at this file. For some reason the correct class isn’t getting applied to the arrow and/or the class is not applying the styles that we actually want.
6. Incorrect started sharing notification on Aspect change
Max: Is this only for local notifications? Not sure where to start, but it could be in the way that contacts or requests are dispatched.
(for the record, completely revamping notifications could be a good community task. It would be a lot of work, but worthwhile since notification data is 1) throw-away-able, and 2) completely local.
Improving Community Engagement in Open Source
by Sean Tilley on April 5, 2012
TL; DR: Diaspora has grown fantastically as a project over the course of the last year, and we’re working to make things even easier for community coders to jump right in and contribute.
With community-driven FOSS projects, there’s something to be said about how a team of core developers interacts with the community around it. It can be said that the very best teacher is experience, and in that same vein, we gain experience by learning from past mistakes.
In the past, our community involvement was something of a sporadic beast, and we came to realize that something had to be done about improving how we work together with developers in the community. In January, we sat down and hammered out a plan to better prioritize how we talk to the people that help us the most.
Things needed to get better, so we emphasized on improving the way we talked to people in our developer community. We focused on lowering the bar to make it easier for a newcomer to contribute, and we documented a solid community process. We want the experience of contributing to our project to be as awesome as using the product we make, and our hard work towards these goals definitely show.
As it stands, we now have a monthly average of 20+ regular contributors constantly making improvements to our codebase, writing documentation, and engaging with us in our user community. Our project is constantly growing better every day because the system that we’ve set up for contributing code is something that community developers actually like. Both the core team and community devs can communicate better before because of the community protocols we’ve put in place.
Percentages depicted represent calculated accepted pull request rates
(For further details, take a look at our GitHub Network Graph)
As you can see from the chart, the amount of accepted pull requests from the previous five months has gone way up. We are now at an 80% accept rate for all incoming pull requests, and the numbers for community contributions are only getting higher. You might ask, why is this?
According to our recent developer survey, our regular contributors make an average of (number) pull requests at any given time. This number is rapidly increasing thanks in part to Bug Mash Monday and our Feature Wishlist.
It’s because we’ve put special emphasis in our community guidelines for code development. We’ve developed a workflow that is very simple, straightforward, and encourages interaction and communication from both the core team and the community members that want to push code.
Another thing to consider is the shrinking amount of code regressions. You’ve probably noticed that Diaspora is a lot more stable now than it was five months ago, and this is because we’ve required that developers include tests with the respective code that they submit. With more tests, we can ensure that less things break with each subsequent commit.
As it stands, our tests are up to an outstanding 2,052 tests that our build system goes through. This includes 1,817 rspec tests, 90 Cucumber scenarios and 235 jasmine tests to test for feature regressions and keep our code stable enough for new feature development.
Finally, it’s also worth noting that the amount of commits themselves are ramping up quite a bit as well. In the previous five months (November 2011 to March 2012), we’ve had an outstanding 1,802 commits on our master branch alone. We would like to thank everyone in the community for their hard work and pitching in, and we hope to ramp things up even more on our road to Beta. We are proud of the improvements we have made to our community process, and are learning ways to make it better every day.
Want to get involved? Keep your eyes peeled for our weekly Bug Mash, and in the meantime, check out our wiki to see how you can get started with development. Hit up our Discuss and Developer mailing lists, and even if you’re not a coder, there are still ways you can help out in our awesome community.
Sources:
GitHub Pull Requests (Note: you most likely need to deselect “Read”, and then “Closed” on the filters)
Bug Mash Monday, Week 5
by Sean Tilley on March 26, 2012
Hey there,
We’ve decided that this week would be a good one to bring back Bug Mash Mondays, as our developer community grows. This month, we had some terrific help from Florian Staudacher for his work on improving embedded content with oEmbed, which has been a long-standing issue. He’s also contributed the new “Show More” function, and he’s contributed to fixing numerous other bugs now.
For this week, we’ve decided to add in some slightly more intermediate bugs alongside some of the easier ones. Check them out below, and if you’d like, feel free to claim them in a comment, or on the mailing list. Check back here frequently, as we do cross things off the list as they are claimed.
1. New own post is not followed by self, according to UI (Claimed, Pull Request)
Dennis: Pretty much all you have to do is make a stub follow object in javascript when you create a post, should be eazy peazy.
2. Commenting on a just deleted post does not result in an error (Claimed, Pull Request)
Max: I am not sure if this is a race condition or whatnot, but it might just be that the wrong error code is getting sent, or we are not checking the validity of the parent post when we save comments.
3. Users not getting “so and so started sharing with you” notifications
Max: Starting with some reproducible tests, and then its back to spelunking in some federation code, which we can discuss on the mailing list.
4. URL is not clickable in RSS (Claimed, Pull Request here)
Max: We use builder templates for the rss feed now, find the text module and make it full html rather than plain text. Check out the atom.builder file to get started.
5. Resharing a post appends it to whatever stream you’re on
Again, after you get the success from the post, we may need some basic checking around what URL you are on before adding it to that pages post collection.
6. Adding long text before @mention breaks mentioned name highlighting
We’re using Jquery Mentions Input http://podio.github.com/jquery-mentions-input/. We’re not exactly sure where the bug is so step one will be reproducing it ;-P. YOu might want to look at updating this library, but I think we’re on the most recent version
We also have one feature open for anyone to claim, feel free to check out our new wishlist for things that would really help progress development along faster.
7. Get Spork running with our test suite (Done!)
8. Modify image branding pack (Done)
What’s So Funny About Peace, Love, and Federation?
by maxwell on March 13, 2012
TL;DR
The time to make federation better is here! We’re planning to vastly increase the reliability of our server-to-server communication scheme. This will make everyone’s experience better, and let us more quickly grow the number of pods in our network. But as a part of this upgrade, we will discontinue support for our existing scheme, as its purpose was to serve as a rough draft of things to come.
Long version
Hi Everyone,
We want to explain some of the improvements and changes that are coming to Diaspora’s federation model.
The Basics: Terms
“Federation” is the word we use to refer to the way we copy posts, comments, profiles, and other information back and forth between Diaspora servers. It’s the foundation of a distributed system like ours, because it enables you to choose a home pod, but still follow and connect with users on other pods. Without it, Diaspora would be just another centralized social network, like the ones we already have.
A Bit of History.
Implementing federation is hard, and lots of smart people have different ideas about how to do it right. When the core team started on this project in June 2010, we wanted to first and foremost get to a place where we could actually SEE what kind of requirements a distributed social system needs. No one had built one at scale before, so while lots of folks thought they knew what it needed, nobody had actually tried it on a system of any significant size.
Therefore, instead of designing the federation scheme in detail ahead of time, we opted for the organic approach and trusted that the right architecture would emerge from the system’s actual usage. We started super basic. The scheme grew in fits and bursts as we added more people to the system, and added likes, private messages, etc., to the list of things that could be copied between servers.
The system we have has served us really well, and I am still happy with our choices. It’s allowed us to see first hand a whole lot about how our distributed system ticks – from what has worked well, to what things are flaky and hard to debug. We also were able to begin building an application that works decently well, and that people want to use. You can think of it like really awesome first draft. Quick, dirty, and (mostly) functional.
The important fact, though, is that we did it this way specifically so we could learn these things. We always planned to take those learnings and re-architect the scheme before going to beta.
So it has come to this.
About a month ago, we announced that we were going to change federation. We wanted to let people know early that a change was coming, and also head off any claims that we never told them we were going to change it. =) This post goes a bit more into how that process is going to work.
The first step for federation is refactor the current system. For non-developers, that means making the existing code work in the same way, but making it easier to understand: more modular code, more tests, clearer phases of what is happening, and better logging for debugging. You can think of it like editing an existing document – it still says the same things, but maybe it’s more clear and organized better.
I’ve started doing this already, and on Github developers can follow along and ask questions if they want.
You may ask, why improve the current system if we’re planning to re-do it? The answer is that it will make it easier to keep the parts that work, and understand more directly the parts and mechanisms we need to fix. This refactoring phase does not change the interface between the pods.
And then…
Phase two will get a little more messy. We’ll be adding some features to the federation scheme, and improving some of our existing features. This means we will be changing the language that pods use to talk to each other.
Some of the things we will be addressing include:
1. Better support for personal pods
2 Reducing delays in federation
3. Improved reliability in message passing
4. Commenting as yourself directly from remote pods
5. Duplicating less information across pods; making your own pod the canonical host of your data
6. Better logging and data around processing federation messages
7. A more modular, decoupled design from the main D* “webapp”
8. Editing posts
and the list goes on….
Our goal has always been to give people ownership and control of the awesome things they make online. We have been making great strides towards that in our user interface, and now it is time to do it at a technical level.
Currently, we are in an exploratory or “spiking” phase in which we are rapidly iterating on ways to achieve these goals. Most of the time, we get an idea, diagram it out, spend a few hours writing code, and then realize that it won’t work for some reason. We throw it all out and start again on the next idea, sometimes going through several of these cycles in a day. But once we have at least a general idea of the technical direction we’re headed, we’ll post it on the wiki for discussion and feedback. And as always, if you have ideas about how we might do these things, you’re welcome to post on the diaspora-dev mailing list. Referencing working code (even if experimental) helps a lot.
Why we won’t be backwards compatible with the current scheme
The current implementation of federation was always meant to be the first draft that got thrown away before beta. Diaspora has spent almost two years as an alpha product, which is longer than the entire lifetime of some projects. We have kept Diaspora in alpha deliberately, because we knew we’d probably be making breaking changes to federation before moving to beta. For that reason, we also didn’t document how it worked, or assign it a version number, and we tried to discourage people from building on it.
All of our code is completely out in the open, of course, so all the information anyone needed to reverse-engineer our protocol has been available on Github. And our community is nothing if not resourceful, so there are two other projects – Friendica and the Pistos project – that have implementations of this old federation protocol that we will be discontinuing. We want to make it as easy as possible for them to keep up and enjoy the advantages of a better-thought-out protocol, so we’ll be publishing detailed documentation once we’ve settled on a scheme. At the end of the day, it’s up to them to choose to stay up to date with us, or not. We want to make it extremely clear that this is not about malice or spite. It’s about moving forward, away from a draft federation model that was never meant to be developed against or forked.
In general, once you see a version in our API documentation, you can be damn sure that we will be supporting that interface with due process. Until then, people asking for backwards compatibility for an alpha level API are at direct odds with people asking us to focus on making federation better.
The end result of this, though, will be awesome. We get a better Federation API, based off of actual user behavior, that actually solves the federation cases we need to make Diaspora imbued in the social fiber of the web.
We’re super pumped to be keeping you all in the loop on our progress, and you should look forward to more blog posts like this one.
Let’s Work Together!
by Sean Tilley on March 9, 2012
Hey guys!
Earlier last month, we launched Bug Mash Monday to help newcomers that were interested in contributing Diaspora code to the main branch. It was a great way for us to test and tweak our contributor policies, documentation, and the general ways our community developers talked to one another. It’s been terrific social way of testing out how our policies work, and what needs to be improved upon. We want to make contributing just as much as a rewarding experience as the software we’re building together.
On that note, we’ve decided to push out some helpful community policies for new contributors as well as guides for getting started in community development. We want to make this process as easy as possible for both the core developers and community contributors. Let’s build something great together.
<3 Sean