current project status

[DanielRuf]

Hi @Dogfalo and @acburst,

as you can see there are many open issues and PR's and it seems @acburst is the only contributor but does not merge any PR's.

Are there plans to add more contributors and pick up development speed?

Because I found a few bugs and I am unsure if PR's will be merged if I provide a fix.

[tomscholz]

Yeah. I was talking to some folks from the gitter channel about making an supported fork of materialize. Please give feedback, if you think that is a good idea :) There are people like @kmmbvnr, @smileytechguy and many more that want to contribute but cant because @Dogfalo doesn't give a damn shit. @Acburst is the only active maintainer, but to handle such a big project alone is impossible. It is Dogfalos project so he has to take care of it or transfer it to another person! There are more than 1000 issues and 300 PRs open! Another way would be to add some maintainers and maybe reset the issue counter! This whole thing really pisses me off.

[DanielRuf]

I totally agree with you. This project has a huge potential and huge interest from other developers but I feel that many things block the further progress of the framework.

We need issue labels, maybe the new projects feature makes also sense to create a backlog of todo issues, current issues in work and create a better structure.

Some third party dependencies should be installed using npm / bower instead of including them directly and the zip file sin the bin directory / the build process could be simplified.

Milestones, some roadmap, better versioning (SemVer as much as possible), just to name a few things which come to my mind.

[Dogfalo]

I am open to the idea of having more maintainers who have had a good history of contributions.

[tomscholz]

Ok, thats cool, but why aren't you accepting any PRs anymore?

[NonameSLdev]

@Dogfalo I think that the first priority for this project is to add more maintainers. Even though I'm new here, it seems clear to me that the project needs more maintainers with more than 1000 open issues and more than 300 PRs, along with stuff (like materialize-picker plugin) that didn't even get in to the project. This project is epic and has huge potential, and more maintainers will help it achieve it's true potential. You created something really epic, help it grow and add maintainers.

[Dogfalo]

To be completely honest with you @tomscholz , it's a mixture of laziness on my part and a general disenchantment in the many PR that I've come across. At one point I kept coming across PR that modified the compiled HTML, JS, or CSS file and it really started to annoy me. But in the end it's no excuse to ignore PR's of course

It would be great if someone is willing to go through the old issues and PR and aggressively close the ones that are no longer relevant or duplicates. I see you have been really active as of late Tom, let me know if you want to help in this regard.

[DanielRuf]

Well, compiled files should be never part of the master branch. Normally there should be an extra branch for a build. And normally you setup npm / Grunt / gulp tasks to do the compile steps and other developers have to go through the npm / bower install and build steps on their own.

But that is just my opinion. A gh-pages or website branch for a complete build is totally ok. For example I strictly separate the source files and the build in this project to ease automatic builds which we could also use here (Travis and other CI solutions): https://github.com/DanielRuf/testblog

Unfortunately I see no build steps here to make reproducible builds and provide the necessary steps which contributors have to go through. ;-)

[NonameSLdev]

@DanielRuf I, in my first commit too almost edited the compiled files. Possible solutions:

1. Move compiled items to a different branch
2. Add a very clear notice, to not commit to compiled files
3. Remove edit access from compiled files to normal users
4. Put them all in a folder called "compiled" so it'd be clear not to touch it

[Dogfalo]

This is a separate concern, but I think maybe we would just add them to git ignore but leave them where are currently are

[DanielRuf]

@DanielRuf I, in my first commit too almost edited the compiled files. Possible solutions:

Move compiled items to a different branch Add a very clear notice, to not commit to compiled files Remove edit access from compiled files to normal users Put them all in a folder called "compiled" so it'd be clear not to touch it

This is what a protected branch is normally for. Currently I miss any documentation for us develoeprs what we have to do and what we should not do when working with the files.

[DanielRuf]

This is a separate concern, I think maybe we would just add them to git ignore but leave them where are currently are

This is just a part of a good solution, the working tree is still full of different directories from the build process or am I wrong?

[DanielRuf]

We could move the docs into a folder called docs/ and use jeykell to generate it 🤔

Definitely a good idea. Sometimes it also makes sense to make an extra repository just for the docs. At least an extra directory is senseful and have an extra branch for the Jekyll hook.

[tomscholz]

@Dogfalo

At one point I kept coming across PR that modified the compiled HTML, JS, or CSS file and it really started to annoy me.

Totally agree

I see you have been really active as of late Tom, let me know if you want to help in this regard.

I would love to

[Dogfalo]

that would change the github pages routing no? wouldn't it solve the problem already if the master branch didn't contain the compiled files?

[tomscholz]

Yeah that would solve the problem with edited compiled files but still the docs inside the repo is a little bit of a mess.

that would change the github pages routing no? wouldn't it solve the problem already if the master branch didn't contain the compiled files?

If you set in the settings that the docs folder is for github pages, then no

[DanielRuf]

that would change the github pages routing no? wouldn't it solve the problem already if the master branch didn't contain the compiled files?

@Dogfalo Do you mean the build process for the website / docs? You can set the branch for the page individually

[DanielRuf]

If you set in the settings that the docs folder is for github pages, then no

Exactly, this is the third option on my screenshot (I don't have a docs directory in this repository si it is greyed out).

[tomscholz]

@Dogfalo Now we are already talking. What is about the @materialize organization? Who owns it and what is/was it for?

[Dogfalo]

We own it, we were just squatting it in case we needed it.

[ncovercash]

To comment on the above - the issue for implementation for a timepicker is several years old, and has many PRs of different implementations, however nothing has been merged

[Dogfalo]

@tomscholz please send me an email so we can exchange a few words.

[tomscholz]

OK. I managed to close like 80-90 issues now. I want to make this as public as possible, but we could also open a new Gitter channel for better communication. Anyhow, what I am trying to say is that it is really hard to cleanup/sort issues. There are still 328 open PRs. These PRs are often in a relation with one or multiple issues. This results in a very complex system. A very anoying thing is that sometimes there are solutions for problems but no one hits the merge button. Many of @DanielRuf PR are good, or is there just something I don't see?

[fega]

Hello @tomscholz, I wanted to help too, Curiously I was reading this topic right now, I send you a private message in gitter

[Dogfalo]

Gitter could be useful for better back and forth. Message me there. Yes I will merge a few today. On Sun, Apr 2, 2017 at 5:32 PM Fabian Gutierrez notifications@github.com wrote:

Hello @tomscholz https://github.com/tomscholz, I wanted to help too, Curiously I was reading this topic right now, I send you a private message in gitter

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Dogfalo/materialize/issues/4423#issuecomment-291026388, or mute the thread https://github.com/notifications/unsubscribe-auth/ACpax-sytIg_wrl1GPiQvg2MeHsQsG_Pks5rsD4pgaJpZM4Mr-g0 .

-- Doggy sends his greetings from Mars.

[fega]

@Dogfalo I already send you a message :smile:

[uok]

hello everyone, thanks for picking up this great project and improving development. Over time I noticed that many issues are just questions from users needing support or sharing ideas. Maybe a simple forum could help to get down the number of open issues leaving only real bugs, branches and PRs? I've seen this working really well on the Syncthing project. Using github labels (e.g. javascript, meteor, css, etc.) also helps (new) developers to work on different parts and bugs

[NonameSLdev]

@uok I don't think we need a forums system, but we could just have issues of different kinds using github issue labels: Problems/Errors, Features/Enhancements, and Questions. The problems/errors could be the default issues with no label, but we'd need a label for features/enhancements and a label for questions, and in the default creating add a note that if it's a question/feature/enhancment to make sure it wasn't asked/suggested before.

[tomscholz]

@NonameSLdev https://github.com/Dogfalo/materialize/labels

[uok]

@NonameSLdev labels can help, but it needs additional time of project owners to assign them. And having ~900 open issues can be a bit overwhelming even if everything is labelled correctly. Edit: new devs and larger team are reducing open issues as we speak 👍

[tomscholz]

@uok 899 issues. There are 899 issues open. @kmmbvnr thanks for the awesome list

[NonameSLdev]

@tomscholz Oh :) @uok Sure, it can be overwhelming and it could be a hassle to assign labels to everything. If the labels already exist all we need to do is to encourage issue commiters to put labels on their issues so they're more organized. So, even if there will be a large amount of issues in the future, it'll be easier to go through them. @tomscholz I don't think that we should add labels to existing issues/PRs as in my opinion it'll be a waste of time. And yeah, clearing all those issues will be a group effort. But hey, around 5 days ago we had ~1000 open issues and we've already reduced that to a 900 thanks to the amazing collaborators/managers :) So we'll make it eventually.

[uok]

afaik only users with write access to the repo can assign labels @tomscholz I updated the post to reflect new awesome 😄

[DanielRuf]

afaik only users with write access to the repo can assign labels

Exactly.

[NonameSLdev]

@uok @DanielRuf Just found that out and was about to write it :) Well why is it like this? If everyone could assign labels (only assigning, not adding new labels) to themselves it could be great for the project.

[fega]

I think that the Enhancements petitions should have a verdict from the leaders of the project in a couple of weeks (maybe two) because there are usually vague and a lot of them are still open since a lot of time ago.

Or we can move the enhancements label quickly to a project tabloid. organized like "In consideration" "Approved" "Denied" It should clean this kind of issues without closing something valuable

[tomscholz]

@fega i dont get it

[uok]

@NonameSLdev Not every person that opens an issue is a developer, e.g. user could open issue "control dishwasher with materialize", label it "critical" and add to next milestone! Some people are new to webdesign, others are JS pros, etc. etc.

Take the Syncthing forum as an example - it works really well as the project has users with many questions and ideas/suggestions. So it would be like "forum = brainstorming and support" and "issues = confirmed todo/new feature list". In addition the devs use labels on Github to inform users what they are working on (e.g. "bug") and what could be picked up by other developers (e.g. "easy") Issues that contain questions or are out of scope are closed as soon as possible and are redirected to the forum.

[fega]

Hello, @tomscholz :smile: Exist a lot of Issues like these:

915

936

2406

1638

1056

601

1024

There are Enhancements, not bugs.

Some of them are vague, that means that you don't know when to close one, why should ask for a clear petition or goal, if this is not provided, close it. if yes, pass to the next options.

Other bunch are unrelated to the project and should fit better in a plugin for Materialize, In that case, a plugin creation should be encouraged and the issue closed.

Also, there are some that are no plans to be accomplished, in those case, I guess that the best option is that the project leaders decide to close it or implement it.

If the maintainers decide to implement it, use something like a project board would be nice to manage this topic.

[tomscholz]

1. Maybe we can try https://waffle.io/ to organize issues better at materialize
2. I created some labels inspired by bootstrap, but I also found these over here very interesting, because they have for each component a label. What do you think about that?

[Dogfalo]

I think component labels isn't necessary. Probably used at Google because they have different people manage different components

[tomscholz]

Ah ok. And another general question: If an issue has a pr, but it is very old and the pr isnt merged. Should I close the issue?

[Dogfalo]

Lets discuss on Gitter

[DanielRuf]

From my side? Sure. We have now a better communication, real progress and some strategy (the projects, labels, Gitter channel and so on). And development is faster now 👍

[Thanood]

I'm just watching your issue closing party and, may i say, it's impressive! 😃

[ncovercash]

yeah, its pretty amazing! already under 800

[uok]

Captain, full speed ahead 🚀 Small suggestion: for clarity keep approved feature requests open

[tomscholz]

@uok Good idea @fega