SCEE
SCEE copied to clipboard
Helium314
identify as SCEE also in notes?
Are there any issues with this? When renaming to SCEE I decided to keep this name, as it contains StreetComplete, as I expect people processing notes would be familiar with it.
Mostly to make it consistent with app name and be clear that it is not StreetComplete.
Mostly to make it consistent with app name and be clear that it is not StreetComplete.
Note that SCEE does identify as "StreetComplete_ee" in changelogs too, not only in Notes. That makes sense to me, as it apart from UI changes and some extra quests (or some quests being asked more often), upstream StreetComplete and SCEE they work pretty much the same - i.e. people wanting to know about stuff done by StreetComplete would likely want to know about changes done by SCEE too. And they can tell the difference easily by that extra _ee.
See https://github.com/Helium314/SCEE/issues/365#issuecomment-1369144337 for some of the reasons for app name change to SCEE.
Why people from Open source world can't talk. Where is problem to merge changes from SCEE and SC and create one app with expert/advanced mode? Less problems, more features. There are a lot of apps with expert mode and there are not end of the world. VLC, JOSM and a lot of other apps can be used by newbie and advanced users. Currently, most of features is and probably will be the same in both apps, but both projects needs programmers and testers. It's not make sense to check the same features in both apps.
It's not make sense to check the same features in both apps.
That is not happening at all. Once you check feature in one app then it will result in edit applied to OSM database which is used by both.
Where is problem to merge changes from SCEE and SC and create one app with expert/advanced mode?
Different people have different design and development plans. That is fine
JOSM and a lot of other apps can be used by newbie and advanced users
StreetComplete is targeting also people who expect editor easier to use than JOSM, without traps
Why people from Open source world can't talk.
This is not what happened. People can sometimes disagree and that is fine, especially in cases where code is freely licensed and different design can be explored.
(also, note that the greatest threat for software like that is primary developing spending their time on something else, so keeping them happy rather than annoyed is a good strategy)
@pawlosck could you be more clear?
Why people from Open source world can't talk
Who/what are you referring to?
Where is problem to merge changes from SCEE and SC and create one app with expert/advanced mode?
Many features in SCEE were declined in SC. So was expert mode, see https://github.com/streetcomplete/StreetComplete/issues/471#issuecomment-846472094
@pawlosck could you be more clear?
My english is not perfect, but I will try to be more clearly.
Why people from Open source world can't talk
Who/what are you referring to?
Generally, people from open source world can't talk. They don't want to cooperate. Instead to cooperate and create one big project, they prefer to create next similar project. For example, a lot of linux distributions are very similar.
Where is problem to merge changes from SCEE and SC and create one app with expert/advanced mode?
Many features in SCEE were declined in SC. So was expert mode, see [streetcomplete#471 (comment) (https://github.com/streetcomplete/StreetComplete/issues/471#issuecomment-846472094)
I know, so problem is with SC team. Expert mode could be added and that's all. I read this comment and owner say that user can broke osm and people could say, that problem is in SC. Manual edition could be added to comment and all people will be know, that was manual change. Personally, If I don't know what specific feature do, I will not use it. Personally, I added few issues with small improvements, but my propositions were declined. One issue was partly implemented (but first was declined) after one or two years.
PS. I am interesting, what app (SC, SCEE or EveryDoor) will be more popular in one or two year.
Generally, people from open source world can't talk.
I do not think that it generally true. In fact, I find it extraordinarily rarely that in open source world "developers can't talk to each other". In my Debian open source system, there are several tens of thousands of open source packages. Yet, I can recall only several situations where developers couldn't talk reasonable about some issue. That is literally less than 0.01% of them. Hardly a majority.
They don't want to cooperate
Again, I find this generally untrue. In vast majority of situations, they do want to cooperate. It is just that often different people have different value systems, and sometimes those values systems are incompatible by their very definition. You can't cook a meal that is "not salty at all" and "quite salty" at the same time. Nor can you make UI that doesn't allow user to create invalid results and at the same time allows users to have full flexibility in what tags will be applied. For some developers, former trumps the latter; for others, other way around.
Instead to cooperate and create one big project, they prefer to create next similar project.
So, your ideal program would be kitchen sink one? One that has every possible feature incorporated into itself? Like Emacs editor? There are people who believe that "small is beautiful" philosophy is vastly superior to such gargantuan software from many standpoints (e.g. make many small tools, each of which does only one simple thing but does it well, and allow them to be combined instead)
For example, a lot of linux distributions are very similar.
There are reasons. (click to expand)
Usually they list them in their about page. You may want to read them before making judgements. For example, some are intended to be small and fast, so they can run reasonable on old computers, and others want to be have as many bells and whistles included by default, but they won't be able to run on less than 4GB RAM. There are some that are intended for tech people for whom where all that annoying window decorations, animations, mouse and other things are just wastefully eating up screen estate, discharging battery needlessly and overall annoying people trying to do some work, and there are others which want to look beautiful to the average users with nice and fuzzy animations. Some want to be simple (think GNOME) so users can't mess it up whereever they click (and if they do, it is easy to recover), and some (think KDE) want to give users all the possibilities for tuning it up to their preference (and thus make it near impossible to find out what went wrong when it does). Some use systemd with a lots of features for easy deployment and developing, and others find idea of putting so much code (and thus so much bugs) into networked process with full root privileges nothing less than a sacrilege against whole sentient universe. Some are intended for kids, and some for whitehat pentesters, and so things that are installed and offered differ greatly. Some need to fit in embedded small systems like your fridge, and some are so optimized for gaming that they wouldn't even manage to start on your average home PC. etc.
If you're not a tech person, here is an analogue: Imagine if someone complained that there are too many different restaurant types, and they should all be joined under McDonalds franchise, which should just extend its menu by few hundred extra pages. Would that sound like a great solution? Probably not. So it is with software - closed source ones too. Open source ones have that great advantage that if you want to change something, you don't have to start your Wendy's from scratch, but you can easily copy existing fast food and just build on that.
I know, so problem is with SC team
There is no "problem", not with SC nor with SCEE teams (which also happen to overlap hugely :smile:) Some people like to eat rice, and some like to eat potatoes. There is no "problem" there either.
Expert mode could be added and that's all
Expert mode has been added. It's called SCEE. Enable the expert mode, and you have expert features; disable it, and you don't. Easy as pie.
Personally, If I don't know what specific feature do, I will not use it.
But that is just you. Personally, if there is speed limit on the road, I will not drive over that speed limit. Yet, millions of people do overstep those speed limits every day. Yours and mine behaviour is just one of the many, and statistics show that the other people will behave differently. Saying "but they should behave just like me" won't make the problem go away.
Personally, I added few issues with small improvements, but my propositions were declined. One issue was partly implemented (but first was declined) after one or two years.
It happens to me too. There are reasons too - usually provided in comment just before closing the issue. Now, sometimes people disagree about those reasons. That is normal too. World would be an awfully boring place if everybody agreed about everything.
Although at first sight most forks seems like splitting the community and duplicity of efforts, all forks are always welcome, but it's better to avoid confusions in the naming.
Not only the notes should be polished, the "New Issue" in github also references StreetComplete. Also i feel that keeping the original readme, specifically the sponsors logos can be misleading.
Although at first sight most forks seems like splitting the community and duplicity of efforts, all forks are always welcome, but it's better to avoid confusions in the naming.
Generally, I agree. But I think that "ee" suffix makes enough of a difference. It still shares 98%+ ([citation needed] :smile:) of the code with regular StreetComplete. I.e. it is not that different. If you are looking for changes done by SC, you most likely want to include changes done with SCEE and other SC forks. And if you are looking for very spefics, you're probably also matching full version text including version numbers, which solves the issue automagically.
e.g. my fork uses "mn" in version number (but it has much less modifications too, so it is 99.9%+ same as upstream). There are ~291 forks of SC on GitHub (and who knows how many elsewhere). Sure, not all of them are active, but imagine if each of them had separate name which did not have common base of "StreetComplete". It would be nigh impossible to make a query which categorizes them in same group, which is common use case.
Not only the notes should be polished, the "New Issue" in github also references StreetComplete.
That is a good point. If you'd like to make a PR @muralito (those are probably located in .github/ folder), I think it would be much appreciated! Be a change you want to see in the world.
Also i feel that keeping the original readme, specifically the sponsors logos can be misleading.
Well it is under section named "original StreetComplete readme below", but I agree the document is long and it perhaps could be missed by quick browsing.
Perhaps it should be moved to separated file named README-upstream.md and just linked from README.md? That would make it clearly separate, but would make merging upstream changes to it more problematic (but it probably does not get that many changes). What do others think?
but it probably does not get that many changes
https://github.com/streetcomplete/StreetComplete/commits/master/README.md
Perhaps it should be moved to separated file named README-upstream.md and just linked from README.md? That would make it clearly separate
makes sense to me
I updated the issues and github issue thing, but I still prefer keeping StreetComplete_ee in notes and changesets and pretty much share @mnalis thoughts on this.